lkml.org 
[lkml]   [1999]   [Nov]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Request for comments (kdev_t and friends...)
Linus Torvalds wrote:
>
> On Fri, 26 Nov 1999, Martin Dalecki wrote:
> >
> > The attached patch is basically showing the full impact of any attempt to
> > enhance the kdev_t struct handling inside the current linux kernel.
>
> I'm pretty convinced that "kdev_t" is just broken.
>
> What we should have is to just make
>
> open_special_device()
> ..
> close_special_device();
>
> and hide a real pointer to a "struct block_device *" (or "struct
> char_device *" as it may be) in the file pointer.
>
> That "struct block_device *" would not have any resemblance to "dev_t" at
> all, and wouldn't have any of these MAJOR/MINOR issues. It would just
> contain the full data - size of the device, offset of the device
> into a "larger" device, pointers to the requests queues etc etc.
>
> So then the lookup would only ever be done once, at file open time. The
> actual read/write functions (and bread() etc) would use the full block
> device pointer and wouldn't need to search for anything at all..
>
> Linus

Linus I subsribe to this with both hands. However I'm just going to use
the
dirty heavy handed, brake it all, pig - patch just as a kind of
intermediary
trampoline to at least identyfy all the involved places. Surely there
is currently far too much kdev_t passing between all the different
components involved. However I have no illusions that it would be
possible
to just jump in with an entierly overwhelmed implementation... one needs
to think about some kind of "transition" path. (Or better call it
"liberation
path ;-).

--
Marcin Dalecki

-
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:55    [W:0.053 / U:0.468 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site