[lkml]   [1999]   [Jun]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Migrating to larger numbers
In article <linux.kernel.7jha8h$v2$>,
H. Peter Anvin <> wrote:
>Followup to: <7jh79o$>
>By author: o.r.c@p.e.l.l.p.o.r.t.l.a.n.d.o.r.u.s (david parsons)
>In newsgroup:
>> In article <>,
>> H. Peter Anvin <> wrote:
>> (dev_t)
>> > I suggest, as you say, a 32:32 split (it's simple).
>> 4 billion major numbers?
>> I'd think a 12:20 split (and a 32-bit number, which has the
>> advantage of being standard C and not depending on gcc or some
>> yet-unapproved standard of the week) would be far more sensible
>> for moderately-sized system (who is going to remember all of
>> these major and minor numbers? I'm still occasionally being
>> bitten by the reworking of the ide1 major number) while something
>> like devfs where the device drivers actually export their
>> interfaces to userspace would be a more maintainable long-term
>> solution.
>Guess what? We *ALREADY* depend on these -- dev_t in libc6 is a
>64-bit number.

Libc6 is an wad of regrettable design decisions that, fortunately,
are not yet required to run a Linux kernel.

Converting dev_t into a 64 bit number (and thus making an earlier
regrettable design decision -- having the filesystem contain magic
numbers for device access -- into a regrettable design decision that's
buttressed by nonstandard GNU constructs) is comparable to putting
the Mississippi in concrete culvert because it overflowed levees
that were put up to make the floodplain safe for subdivisions.

david parsons \bi/ Libc 4 or fight.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:52    [W:0.164 / U:0.044 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site