[RFC] change in /proc/devices

[david parsons]

Alexander Viro wrote:
 
> On Thu, 27 Jan 2000, david parsons wrote:

> >      0300[40] means that I have to know that a major is the first 8 bits.
 
> No, you don't. mknod(2) takes dev_t as an argument.

    But mknod(8) doesn't, and userland daemons like MAKEDEV pass around
    majors and minors like candy;  since MAKEDEV is the only userland
    app that I know about that does poke around in /proc/devices, it's
    the format I'm paying attention to.   If Unix-compatability isn't
    very high on your list, a hack to mknod(8) to accept a single dev_t
    argument would nicely circumvent that problem.

> >         Need you ask?  If I wrote a lkm, I'd have it export this
> >         information as a filesystem so I could mount it on /dev like G-d
> >         himself intended, and then I could maybe wedge a 2.4 kernel
> > 	onto a Mastodon boot floppy [*].
> 
> Urgh... Then you will be better off patching register_disk().

    If I scream about register_disk() changing, nobody will pay attention
    to me.   /proc/devices, being part of procfs and therefore Unclean,
    is less likely to being changed out from under me without warning.
 
> > 	david parsons \bi/ [* Anybody know of a good way to trim 300k from a
> >                    \/                                       2.3.x zImage? ]
> 
> BTW, I suspect that you might win quite a few blocks if you will modify
> insmod and teach it to load gziped modules. Or just use cramfs...

    Nope.  My install floppy already compresses the rootfilesystem. I
    could get back 180k if I discarded the whole scsi layer and instead
    used bios int14 to talk to disks, but then I'd have to either carry
    around two separate kernels (a stripped down one for the installer,
    and a fully-bloated one for the core Mastodon package) or I'd need
    to tweak the kernel so I could inherit-mount drivers on top of an
    int14 base.


                  ____
    david parsons \bi/ I could just discard the spiffy pcmcia autoloading,
                   \/                             but That Would Be Wrong.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo en vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/