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

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

david parsons (orc@pell.portland.or.us)
Thu, 27 Jan 2000 03:14:48 -0800 (PST)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Guest section DW: "Re: [RFC] change in /proc/devices"
- Previous message: Catalin BOIE: "Re: 2GB limit (more info)?"
- Next in thread: Guest section DW: "Re: [RFC] change in /proc/devices"
- Reply: Guest section DW: "Re: [RFC] change in /proc/devices"
- Reply: Alexander Viro: "Re: [RFC] change in /proc/devices"

Alexander Viro wrote:
>
>
>
> On Thu, 27 Jan 2000, david parsons wrote:
>
> > I'd prefer a postfix notation that separates out major and minor
> > numbers, like so:
> >
> > hda 03 00-39
> > hdb 03 40-79
> > hde 21 00-39
> > hdf 21 00-40
> > sda 08 00-09
>
> Erm... It was in hex ;-)

hda b 03 00-3f
hdb b 03 40-7f

Happy? ;-)

> > Because that would explicitly show the major and minors, instead
> > of having to rely on hidden magic to partition the majorspace.
>
> 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.

0300[40] means that I have to know that a major is the first 8 bits.
03 00-3f means that I need to know the major is the first field, and
that the minors run from 0 to 3f. This is MUCH better for userland,
because that's one less stupid detail that apps have to remember.

> > And, actually, while I'm dreaming, I'd love to have it be:

> > device type major minors
> > hda b 03 00-39
> > hdb b 03 40-79
> > hde b 21 00-39
> > hdf b 21 00-40
> > sda b 08 00-09

> Maybe, but I'ld rather keep character ones away from that. If we will
> start touching them (and you will be the first to cry bloody murder) I'ld
> prefer to keep them in a separate file.

They're not in a separate file right now, and putting them into
the same file reduces the rooting around.

> > ____
> > david parsons \bi/ It's not a devfs, but this is a format I can do
> > \/ something with either in userspace or in a lkm.
>
> 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 [*].

> ObBletch: All this stuff bears some uncanny resemblance to
> IP-space-dries-up fights. I just hope that we will not end up with an
> analog of NetSol<spit> on hands...

HPA as SAIC and Linus as the Department of Defense?

The mind, it boggles.

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

-
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: Guest section DW: "Re: [RFC] change in /proc/devices"
- Previous message: Catalin BOIE: "Re: 2GB limit (more info)?"
- Next in thread: Guest section DW: "Re: [RFC] change in /proc/devices"
- Reply: Guest section DW: "Re: [RFC] change in /proc/devices"
- Reply: Alexander Viro: "Re: [RFC] change in /proc/devices"