Re: SGI changes [mail.linux-kernel]

Scott Lurndal (slurn@griffin.engr.sgi.com)
Mon, 13 Dec 1999 17:19:06 -0800 (PST)


------ Forwarded Article <833tj1$cqm2f@fido.engr.sgi.com>
------ From Alan Cox <alan@lxorguk.ukuu.org.uk>

> be short and simple. Having NOT looked at SGI's code, and not intending on
> offending anyone what makes there code more difficult to maintain? Or more
> particularly what makes code difficult to maintain in the first place?

The big one for some of it is modularity. Linux is very modular and its
important it stays that way - thats why my tree can often differ from Linus
by 1Mb and I can throw in Linus 2.3.3x pre patches with no clashes and no
changes needed to fix up afterwards.

That makes for maintainability and debuggability.

Alan

------ End of Forwarded Article

Alan,

How does the sd_raw_read/sd_raw_write functionality reduce linux'
modularity? While it is not a generic solution for some single-board
RAID solutions, it does provide for modular access to SCSI and FiberChannel
devices without:

1) Buffer header allocation/deallocation
2) I/O request breakup into buffer-cache managable chunks and
3) The somewhat counter-intuitive (for long-time unix folks) /dev/raw
API (a new, non-standard API with significant restrictions).

Ideally, each driver which supports input and output operations into the
user address space should provide an entry point in the file_operations
vector for that device, and that is indeed what was done in the sd_raw_rw
code. Note that while there is a call to map_user_kiobuf in sd_raw_write
and sd_raw_read, which should be moved to sys_read/sys_write, etc., that
was considered to be too large of a change for the 2.2 series of kernels
which we developed the raw I/O patch on.

I'd also like to see the file_operations vector contain separate entry
points to initiate an I/O request (which would return before I/O complete),
and another entry point to poll/wait for the request to complete. This
would be extremely useful for kernel-level, non-threads-based asynchronous
I/O support.

scott

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