The design of mdev (mini-udev for busybox).
rob at landley.net
Mon Dec 5 01:40:23 UTC 2005
On Sunday 04 December 2005 16:14, David Seikel wrote:
> > For both of these, what's your proposed use case? (What empty files
> > or directories outside of /dev would you want to create?)
> I have attached what I currently use in My Linux.
I ask for a use case, you give me code.
Rummage, rummage, rummage...
Having looked about your code, I believe I can say with some authority that
you really, truly, _deeply_ need to look into initramfs. You can have all
that crud in the gzipped cpio archive built into the kernel image, and the
kernel will extract it for you on boot.
> It doesn't do udev or hotplug type stuff, but does create /dev entries.
> It is a busybox
> module. I intend to turn this into a combined create things at boot /
> create filesystem structure for installing thing. Yes, all things are
> currently hard coded into the code.
Sounds deeply uninteresting to me. What does this have to do with busybox?
> > > Creating non existing directories as it goes. The initial /
> > > separates these from the device entries in the config file,
> > A) Suddenly the config file has to know whether you're operating
> > on /dev or on /mnt/dev, which I was trying to avoid.
> I'm not sure exactly how mdev was going to work, but for instance
> cd'ing to /dev first, then create what's in the config file, relative
> paths will automatically end up relative to /dev, and absolute paths
> will automatically end up absolute.
Sure. That's a side effect I don't see a major downside of leaving alone.
But why are absolute paths interesting?
> With that sort of arrangement,
> there is no having to know where you are operating, and no having to
> interpret the beginning of the name.
I wasn't planning on having the code care. This config file belongs to root:
the user does something stupid they get to keep the pieces.
> > > I have experimented with this sort of thing for My Linux, and found
> > > that it helped to keep the size of my initrd down. The extra code
> > > and config file used less bytes than actual directory entries on
> > > the ram disk.
> > Ram disk or initramfs? This is for initramfs, where the directory
> > entries are in a gzipped cpio archive, which is fairly efficient.
> Ramdisk. As I said, my experiments with the attached code showed that
> it was worth it.
This is still sounding totally unrelated to mdev. Sounds like you want to use
or extend makedevs. Or use initramfs.
> > I'm not convinced it's an improvement over having an init script.
> It's a case of every byte counts, and if you don't add it to mdev, I'll
> just be replicating a portion of the mdev code in my mkrootfs.c.
My deep and abiding lack of caring truly cannot be expressed in words. You're
already talking about something hardwired, and I'm talking about efficient
The only reason _I_ care about putting anything other than device nodes
into /dev is that the tmpfs mount means it starts empty, so something has to
populate it and it traditionally has a couple of subdirectories in there that
we might as well handle.
> I just saw a chance to condense very similar code into one. Since mdev
> will likely already have the great majority of the code needed to do
> what I want, I don't see the point of reinventing the wheel when only
> a very small extension of what you are doing will do the job.
It's possible that what I'm doing will be useful to you. I hope so.
Creating files, however, is something mdev is highly unlikely to do (except
via shellout) because there's no sane way to specify the contents. I'd
suggest getting initramfs to populate a subdirectory with your stuff and then
either living in initramfs or doing a cp -r to the final root.
> > Keep in mind I'm redoing bbsh to be actually useful during 1.2 as
> > well.
> That I am eagerly looking forward to. Should help to reduce my own
> code a bit to.
Won't be until after New Year's. I'm hoping to get my firmware 0.9 release
out tonight (caffeine will be involved) and attack the web bug list tomorrow
to put together a -pre2 for wednesday.
Plans and what actually happens aren't always on speaking terms around here,
Steve Ballmer: Innovation! Inigo Montoya: You keep using that word.
I do not think it means what you think it means.
More information about the busybox