Re: RFC on raw IO implementation
Hi, On Thu, 27 May 1999 22:18:50 -0700 (PDT), Linus Torvalds <[EMAIL PROTECTED]> said: > I care not one whit what the interface is on a /dev level Fine, I can live with that! > the only thing I care about is that the internal interfaces make sense > (ie are purely based on kernel physical addresses, and have nothing at > all to do with user virtual addresses). > Having a simple translation layer to old-fashioned UNIX semantics makes > sense, but doesn't mater from a kernel internals standpoint, so I don't > find it all that interesting. Agreed, and the current code keeps that distinction clear. The raw device code generates kiobufs from user space but there is no trace of the origin of those pages when we pass them to the IO layers: all passing is done by containers of arbitrary physical pages. > IF you think the translation layer matters to the internal implementation, > then I can only say that something else is broken, and no, the patches > wouldn't get accepted. That's fine --- it is purely the top-level API for backwards compatibility raw character devices I was worried about, since that's the only part of the code which may give rise to compatibility issues if people start using the raw diffs against 2.2. --Stephen
Re: RFC on raw IO implementation
On Sat, 29 May 1999, Stephen C. Tweedie wrote: > > Agreed, and the current code keeps that distinction clear. The raw > device code generates kiobufs from user space but there is no trace of > the origin of those pages when we pass them to the IO layers: all > passing is done by containers of arbitrary physical pages. Cool. That way we can use it for other things. Who knows, maybe we'll need to have kernel support for web-serving to beat the benchmark crap of certain systems that shall remain unnamed ;) > That's fine --- it is purely the top-level API for backwards > compatibility raw character devices I was worried about, since that's > the only part of the code which may give rise to compatibility issues if > people start using the raw diffs against 2.2. Happily you still have to switch the devices around (b->c) in /dev, so I guess an old installation wouldn't ever really notice, while a new installation can take advantage of the true raw devices if it wants to, which it probably does. Linus
Re: RFC on raw IO implementation
On Fri, 28 May 1999, Stephen C. Tweedie wrote: > > Is this interface something you are likely to accept for 2.3 if we can > agree on the internals? I care not one whit what the interface is on a /dev level - the only thing I care about is that the internal interfaces make sense (ie are purely based on kernel physical addresses, and have nothing at all to do with user virtual addresses). Having a simple translation layer to old-fashioned UNIX semantics makes sense, but doesn't mater from a kernel internals standpoint, so I don't find it all that interesting. IF you think the translation layer matters to the internal implementation, then I can only say that something else is broken, and no, the patches wouldn't get accepted. Linus
RFC on raw IO implementation
Linus, We talked before about a general purpose kernel IO buffer mechanism that can be used to pass arbitrary data around for IO, and how that could hide the mess of zero-copy raw user IO from the kernel IO layers. I have a working implementation, although I'm still soliciting input as to what the kernel API needs to be capable of (VIA architecture, fast networking, 3D direct rendering and filesystem people have all expressed interest in an IO layer which permits seamless zero-copy IO without necessarily going through user space). However, before I encourage too many people to test the current code (which right now is limited just to raw disk IO), I want to ask if we can agree on an ABI for the raw character devices so that any future kernel-internal work doesn't mess up the way the raw devices look to the user. What the patch offers right now is a general purpose raw IO major character device. Minor number 0 is a control device which accepts ioctls to bind the other minors to a given block device major/minor pair. As a result, any block device can be accessed as a raw device, and the raw devices exist in the /dev namespace as character devices just as they do on traditional Unix raw IO implementations. Opening the raw device sets the blocksize to 512 if it is not already mounted, for compatibility with applications which expect this. Is this interface something you are likely to accept for 2.3 if we can agree on the internals? --Stephen
