From: Andries.Brouwer@cwi.nl
Date: Sat, 8 Mar 2003 21:26:15 +0100 (MET)
Message-Id: <UTC200303082026.h28KQFN04439.aeb@smtp.cwi.nl>
To: Andries.Brouwer@cwi.nl, akpm@digeo.com, alan@lxorguk.ukuu.org.uk,
       greg@kroah.com, hch@infradead.org, linux-kernel@vger.kernel.org,
       torvalds@transmeta.com
Subject: Re: [PATCH] register_blkdev
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1522
Lines: 40

>> That's why the character device code should get a similar massaging

> I agree, I thought this was a 2.7 change, but it's looking like people
> want this change sooner :)

There is no need to do all of that. Going to 32-bit dev_t
is trivial, not a major restructuring.

Three minutes editing of kdev_t.h and posix_types.h and you have it.
Boot the kernel and it runs fine.

However, it can be crashed from userspace, so before we do
the three minutes editing the audit is needed.
Look at the patch for raw.c I posted a few hours ago.
One trivial test.

If we do it as Alan suggested even this one test can be
avoided in most places.

> If people really think they need a 32bit dev_t
> we should just introduce it and use it only for block devices
> and stay with the old 8+8 split for character devices.

Of course discussing the future and how the cake should
be divided once we have it may be of interest - but let
us bake the cake first. The work required is entirely
independent of the size and structure of dev_t.

Andries - curious whether 2.5.65 will show progress


[not that the road isn't long - once the kernel is happy
there are some glibc details - strange enough glibc uses
a gigantic dev_t but simultaneously assumes that major and
minor only have a few bits]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/