The design of mdev (mini-udev for busybox).

[David Seikel]

On Sun, 4 Dec 2005 15:35:30 -0600 Rob Landley <rob at landley.net> wrote:

> On Sunday 04 December 2005 14:24, David Seikel wrote:
> > On Sun, 4 Dec 2005 13:01:42 -0600 Rob Landley <rob at landley.net>
> > wrote:
> >
> > I would add one more thing, probably for the initial -s scan.
> > Create empty directories and empty files -
> >
> > /path/to/directory/ 0:0 600
> > /path/to/file 0:0 600
> 
> A) When we don't specify the type, we assume it's a device, not a
> file.  Files would have to be tagged just like any other device type.
> 
> B) The paths are assumed to be relative to the dev directory.  (Which
> doesn't _have_ to be /dev, presumably you can run it from initramfs
> on /mnt/dev before doing a switch_root into /mnt.)
> 
> 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.  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.

> > 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.

/mnt/dev?
 
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.  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 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.

> 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.  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.

> 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.

-- 
Stuff I have no control over could be added after this line.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: mkrootfs.c
Type: text/x-csrc
Size: 10552 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20051205/b68c118f/attachment.c 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20051205/b68c118f/attachment-0002.pgp