Linux-kernel mailing list archive 2000-04,: Re: [RFC] change in /proc/devices

# Re: [RFC] change in /proc/devices

Alexander Viro (viro@math.psu.edu)
Thu, 27 Jan 2000 09:00:59 -0500 (EST)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Andrej Todosic: "eepro and 2.3.39and 2.3.40 ( update)"
- Previous message: Robert Collier: "Re: 2GB limit (more info)?"
- In reply to: david parsons: "Re: [RFC] change in /proc/devices"

On Thu, 27 Jan 2000, david parsons wrote:

> > Argh... I'ld _really_ like to get rid of major/minor stuff wherever
> > possible. Besides, says who that we will not get a driver for terabyte
> > hardware raid where one can expect more than 256 partitions?
>
> Nothing. That's the advantage of separating out the major and
> minor numbers -- if you explicitly list the major and minor
> numbers, userland apps don't have to know how wide a major is
> to do something with it.

Erm... Flat address space is Good Thing(tm). Very small part of userland
needs to know about the major size.

> 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. Just feed the thing
as is and don't bother with the splitting it up. stat(2) also returns
plain dev_t, so...

> > In lkm you will be able to do much better - another question being what
> > would you do with the results...
>
> 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().

> david parsons \bi/ [* Anybody know of a good way to trim 300k from a
> \/ 2.3.x zImage? ]

I don't promise 300k - core of each driver will remain as-is, but glue is
going to shrink. As soon as I'll sort the IDE stuff out[1] I'll submit the
next patch to Linus. And it looks like it will be the last one _adding_
code - from there on it's a big butchery.

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

[1] bloody thing works, but I'ld like to know what (if anything) stops it
from breaking apart...

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

- Next message: Andrej Todosic: "eepro and 2.3.39and 2.3.40 ( update)"
- Previous message: Robert Collier: "Re: 2GB limit (more info)?"
- In reply to: david parsons: "Re: [RFC] change in /proc/devices"