#2550: Udev bootscript enhancement
-------------------------+--------------------------------------------------
Reporter: mickb | Owner: lfs-b...@…
Type: enhancement | Status: new
Priority: normal | Milestone: 6.6
Component: Bootscripts | Version: SVN
Severity: minor | Keywords:
-------------------------+--------------------------------------------------
Comment(by br...@…):
> I use udevd over µClibc.
That one, I'm pretty sure, can break at any time. The official uclibc
support was yanked from udev about 3-5 years ago, when they moved to
requiring glibc's fnmatch() to match attributes, and yanked all the
fnmatch()-doesn't-work workaround code.
Now it's possible that this specific function was moved into uclibc
shortly afterward, but when inotify support, signalfd/eventfd usage, etc.,
were added, no consideration at *all* was given to whether these functions
were available in uclibc or not.
(Which is why I just copy glibc in. It's not like it's *that* much
bigger, and it uses *no* memory after the system is booted anyway. And
it's fully supported by upstream.)
> Performing the same check on /dev does not make any harm
No, it doesn't. But (I don't think) it shouldn't be needed either. There
is at least one other reason you wouldn't want to preserve the initramfs's
/dev already, so in light of that, I'm not sure we should make it easy.
:-)
But maybe none of the other editors agree. :-)
> the "mode" indication already exists in the udev script.
Hmm? Not here...
Wait, sorry, I was looking at the wrong bootscripts tree. You're right,
it is there, so never mind that one.
> allowing theoretically 1 GB of RAM for /dev, for example, troubles me a
bit :)
But what I'm saying is that if it's ever actually a problem to allow it
1G, then you're doing it wrong. :-) (Also, can't tmpfs be swapped if
needed?)
Whereas if you add a limit, and then a future udev decides to make its
database (in /dev/.udev) into small files (with nonzero size) instead of
symlinks, then at about 4K entries or so, you run out of room. (Assuming
64 bytes per entry. And assuming there's no block size on a tmpfs, which
may or may not be true: you might be forced to use 1K per file, which
would be only 256 entries.)
The chances of that might be slim, but given that the format of the
database can change at any time, I wouldn't rule it out...
--
Ticket URL: <http://wiki.linuxfromscratch.org/lfs/ticket/2550#comment:3>
LFS Trac <http://wiki.linuxfromscratch.org/lfs/>
Linux From Scratch: Your Distro, Your Rules.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-book
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
