On Mon, 3 Oct 2005, Ryan Anderson wrote: > On Mon, 2005-10-03 at 23:26 +0200, Tomasz K³oczko wrote: > > If (cytation from Linus) "a 'spec' is close to useless" .. > > Q: why the hell in kernel tree is included Documentation/ subdirectory ? > > Is it raly content of this directory is "close to useless" or maybe it not > > contains some specyfications ? :> > > Let me rephrase what Linus said, to help remove the misreading that > seems so common today. I think a fair rewording would be, "A spec is a > guideline. When it fails to match reality, continuing to follow it is a > tremendous mistake." > > Additionally, I think the overall LKML feeling on hardware specs and the > corresponding software abstractions to deal with it can be summarized > something like this: > > When the spec provides a software design that doesn't fit into the > overall structure of the Linux kernel, the spec should be treated as a > suggestion for a software design. The *interface* that the spec > documents should be followed, where it moves out of the overall > structure, but internally, a design that fits into the Linux kernel is > more important than following a spec that doesn't fit. Please lets design against the transport or FSM of the storage transport and never see data again. NCITS specs generally (used loosely) define the boundary conditions for stable operations. One of jewels of linux in the past which (hopefully was fixed, was 1.2.X-2.5.X thingy) was buffer_head walking and release to satisfy transfer of data-blocks of a spindle against the data-blocks of the kernel. Spindle must win or one can not insure data integrity, thus the advent of BIO's from BH. Linux changed to conform to data integrity issues. Somedays, Linux's API's or designs are OTS (Over The Shoulder). You get crap all over your back, if you reach OTS to finish your washroom business. It is functional but ends up stinky and messy. This thread is getting longer and I just added to piles ... Sigh Andre - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
