Surely there's a way to genericize this. Even on processors that don't _come_ without an mmu, in ultra-low-memory environments doing without page tables can still be a win sometimes... Considering

In the kernel. For arches that don't currently do any non-mmu it is usually the code in arch/foobar/mm and often some in arch/foobar/kernel that has no concept of operating with the MMU turned

Architectural support in the kernel, or in the emulator? Not having nommu support for i386 is one thing, but why can I boot a nommu arm under qemu? (What's involved in nommu archiectural support?

ugh, SkyEye is such crap. time really should be spent on better systems like QEMU (even the GNU/sim). -mike

uh, the Gentoo usage was phased out years ago, and was only introduced in the rocky years between devfsd and fully dynamic udev because the overall system wasn't up to the task yet. -mike

This sounds interesting. Do we have any first-order approximation of the amount of time udev spends probing and setting up devices using discovery? I don't want to chase this down to find out we

Dear Lucas De Marchi, In message <CAMOw1v4Zj8XVA35b-TXmuxmJUTha0RMbXS3_c-tT75Nbei1B4g@...> you wrote: I don't want to argue about the approach. Probably each solution has it's own set of

<lucas.demarchi@...> wrote: This was an ugly hack used by many distros, not just yocto but also Gentoo. devtmpfs anyone? :-) That's right. It's not about device nodes, but also loaded

Hi Wolfgang I didn't know this existed, but IMO is the wrong approach. If all you want is a static /dev, you could have that partition already done, without untar anything. Yeah, that's one of the

Dear Lucas De Marchi, In message <CAMOw1v5YNCyX1Qri5NyU2k_Q6GAbJ-fRM1B8A7wsVCBMRxAYCQ@...> you wrote: Yocto uses this feature in a number of configurations; it creates an archive

No. It comes down to architectural support. There are a few that do it. I have ColdFire hardware with MMU, it can be compiled and run either with or without MMU enabled (by flicking the

Hi, sorry for the delay. I hope it's still possible to consider this proposal for this year. Caching of information on udev ; Summary: Caching device information on udev ; Proposer: Lucas De Marchi

Hi Thomas, Yes, it does. FWIW the 5208 (and specifically the M5208EVB) is a target I test with a lot. All recent mainline kernels work on

Greg Ungerer <gerg@...> a écrit : Well, either Qemu pretends to emulate a 5208 and it should support the dual stack pointer thing, or it shouldn't pretend to emulate a 5208. Am I correct

Hi Thomas, Ah, ok. I only put the dual stack pointer support in a year or 2 back. And it is only supported on the more modern ColdFire's, guess the QEMU support is for the simpler parts :-) Well,

Hello Greg, Greg Ungerer <gerg@...> a écrit : The kernel patch is at http://lists.busybox.net/pipermail/buildroot/2012-April/052585.html, hidden inside a Buildroot patch. I haven't posted

And on the MMU front: I once limited Fast RAM on an Amiga to 2 MiB, and booted Linux into X with twm and xterm. The 2 MiB did not include frame buffer memory, as that's part of Chip RAM. This was just

That's very interesting, but I'm unlikely to have time to folow up in the next few weeks. (I'm already investigating the full m68k support qemu is growing in the q800 branch Laurent Vivier's doing on

Um, they're explicitly replacing desktop computes. Mainframe -> minicomputer -> microcomputer -> smartphone. This is the third regeneration of the computer industry (we're up to Tom Baker). Nobody

I'm impressed. Rob -- GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code. Either it's "mere aggregation", or a license violation. Pick one.