lkml.org 
[lkml]   [1999]   [Jun]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Migrating to larger numbers
Date
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.

-hpa


--
"The user's computer downloads the ActiveX code and simulates a 'Blue
Screen' crash, a generally benign event most users are familiar with
and that would not necessarily arouse suspicions."
-- Security exploit description on http://www.zks.net/p3/how.asp

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

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