Re: [RFC] Add support for semaphore-like structure with supportfor asynchronous I/O
From: Trond Myklebust
Date: Mon Apr 04 2005 - 13:03:57 EST
mà den 04.04.2005 Klokka 12:22 (-0400) skreiv Benjamin LaHaise:
> > Your approach looks reasonable and simple enough. It'd be useful if I
> > could visualize the caller side of things as in the NFS client stream
> > as you mention - do you plan to post that soon ?
> > I'm tempted to think about the possibility of using your iosems
> > with retry-based AIO.
>
> I'm not sure I see the point in adding yet another type of lock to the
> kernel that has different infrastructure. This will end up with much
> more code changing to adapt to the new iosems, rather than just using a
> new primative on the existing semaphores.
The point is to avoid having to develop and test 23 different and highly
arch-dependent (and hence non-maintainable) versions of the same code.
In particular note that many of those architectures appear to be heavily
over-optimized to directly inline assembly code as well as to use
non-standard calling conventions. They all also manage somehow to differ
w.r.t. spinlocking conventions and even w.r.t. the internal structures
and algorithms used.
IOW: the current semaphore implementations really all need to die, and
be replaced by a single generic version to which it is actually
practical to add new functionality.
Failing that, it is _much_ easier to convert the generic code that needs
to support aio to use a new locking implementation and then test that.
It is not as if conversion to aio won't involve changes to the code in
the area surrounding those locks anyway.
Cheers,
Trond
--
Trond Myklebust <trond.myklebust@xxxxxxxxxx>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/