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

[Rob Landley]

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:
> > Anyway, this is what I'm thinking about.  Comments?
>
> 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?)

Keep in mind that there is such a thing as an init script.  Even if mdev is 
mounting tmpfs on /tmp, you can still have the init script do stuff 
afterwards.  I'm not trying to get this sucker to replace init scripts, I'm 
only thinking of adding the ability to create directories and such to make it 
so all the /dev configuration is in one place.  I'm not 100% certain it's 
worth it, and it would _definititely_ be a compile-time option to _not_ add 
that bloat.

> Oh, and add ordinary links -
>
> /path/to/link -> /path/to/file

Again, the absolute paths are for...?

The catchall is shellout capability.  Right after this device is created, run 
this script.  (If you want to get picky you can create it with permissions 
000, and then rename it before doing a chmod to something people can use.)

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

B) Why should an absolute path indicate the _type_ of the file?  (When this is 
otherwise indicated by a _trailing_ character that would not ordinarily occur 
in a file?)

I glossed over "quoting and escaping" ye olde filename.  Not sure it's worth 
it.  Leaning towards "not", actually...

> and the trailing / separates directories from files.

That was already in the initial design.

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

> Actually, I went one step further, I added the contents of short 
> text files with \n and \t expansion to the config file.  Don't know if
> that should be included though, as it makes parsing the config file
> harder.

I'm not worried about parsing difficulty so much as "not going there" because 
there is such a thing as an init script.  This isn't replacing that.  "mkdir 
-p" is a perfectly acceptable way of scripting directory creation...

> Default owner, group, and permissions helped keep the config file size
> down to.

Yeah, hence the ".* 0:0 600" entry at the end of the file.  I suppose I could 
hardwire in a default if nothing matches...

> I suspect this will not add much to mdev, as you have most of the
> needed code already.

I'm not convinced it's an improvement over having an init script.  Keep in 
mind I'm redoing bbsh to be actually useful during 1.2 as well.

Rob
-- 
Steve Ballmer: Innovation!  Inigo Montoya: You keep using that word.
I do not think it means what you think it means.