Re: I request inclusion of SAS Transport Layer and AIC-94xx into the kernel

[Tomasz Kłoczko <kloczek@rudy.mif.pg.gda.pl>]

On Mon, 3 Oct 2005, Luben Tuikov wrote:

> On 10/03/05 12:35, Andrew Patterson wrote:
> > On Mon, 2005-10-03 at 18:29 +0200, Marcin Dalecki wrote:
> > > They give a means of possible synchronization between beneviolent
> > > users, but not a mandatory lock on the shared resource.
> >
> >
> > Nor do they protect against external events, such as disk
> > insertion/removals, and someone kicking a cable.
>
> As has _always_ been the case in UNIX:  Provide capability,
> not policy.
>
> The more things are off loaded to userspace the better.
>
> Look at it this way: the deadbolt on your house door does
> not _eliminate_ the possibility of someone cleaning out
> your house, even if you have a security system and/or
> a guard dog.

But using fs like "presentation" layer have some additional "possibilities"
for race conditions because between open() and flock() some other process
can try open the same file. Also this semantics does not provide locking
tree or subtree of files (do I mention procfs and sysfs do not support
locking ? :)
Next is time/cpu concumption because operate on fs like structures
requires open() -> (flock() ->) read()/write() -> close() .. three or more 
context swiching. This is main reason why simple ps takes so many time on
Linux.

Something like simple MIB/OID like semantics for read, write, lock single 
OID or subtree could be very good to mandatory locking for operate on
atributes sets and probably will take less memory than sysfs.

<mode=cynic>
But I know this is like fantasy because seems no one want work on
stabilize kernel API. Even more .. Documentation/stable_api_nonsense.txt
included in *stable* line documents real kernel strategy .. it is 
*pure folclor* (because from this is possible suck something like: "we are
using specyfication: 'we are hate use specyfications'").
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 ? :>
If it is true maybe better will be remove this ? ;->
Maybe after removing Documentation/ with stable_api_nonsense.txt some 
people will can grant permission to start thinking on prepare
specyfication for kernel API usable in longer chunk of time (?)
</mode>

kloczek
--
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek@rudy.mif.pg.gda.pl*