Re: Migrating to larger numbers
david parsons (o.r.c@p.e.l.l.p.o.r.t.l.a.n.d.o.r.u.s)
7 Jun 1999 16:34:32 -0700
In article <linux.kernel.7jha8h$v2$1@palladium.transmeta.com>,
H. Peter Anvin <hpa@transmeta.com> wrote:
>Followup to: <7jh79o$ov1@pell.pell.portland.or.us>
>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: linux.dev.kernel
>>
>> In article <linux.kernel.375B224A.6F78B302@transmeta.com>,
>> H. Peter Anvin <hpa@transmeta.com> 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 majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/