Re: Interface for SCSI transactions ?

[olafBuddenhagen]

Hi,

On Sun, Oct 09, 2011 at 12:48:37PM +0200, Thomas Schmitt wrote:

> > Furthermore considering that the kernel driver interface will be
> > temporary anyways, I'm not really concerned about compromising the
> > Hurd architecture...
> 
> Time is running slowly in the Hurd universe. A temporary decicision
> can last for quite some time.

It may last quite some time in a slow Universe -- but I very much hope
that nobody will try doing other work in this area during that time :-)

> [about future widening of the parameter list] :
> > we can just as well explicitly introduce a new RPC with different
> > parameters, while keeping the original one unchanged. That's the
> > proper way to provide client/server compatibility in the Hurd.
> 
> So the case of fanned-out parameters could start with a narrow set of
> parameters which currently are served by the SCSI or ATAPI transaction
> calls in gnumach.

Exactly.

> > It's enough to know that we can easily keep compatibility at the RPC
> > level whenever we want/need to -- without any manual marshalling
> > ugliness :-)
> 
> So we decide for fanned-out RPC with only those parameters which
> currently can be served by the two existing transaction calls in
> gnumach?

Well, if the decision is up to me, then yes :-) Would like to hear some
word from Samuel though...

> [putting cars on transport vehicles]
> > The Tunnel trains can transport passengers directly, but they can
> > *also* cars. This is useful, as taking the car along can be
> > convenient for the travelers before/after passing the Tunnel;
> 
> That's what i deem appealing with the idea of a generic system call.

No, that's not the case here. Again, we wouldn't use the manually
marshalled inner RPC for anything *but* passing the tunnel. It wouldn't
be used before or after passing it. It would be a car serving no other
purpose but being loaded on the train.

Well, perhaps such comparisions aren't so useful after all... ;-)

> A fanned-out RPC has no place in struct device_emulation_ops.
> Especially if we explicitly plan it to be accompanied by improved
> versions in future.

Well, hopefully an improved version will only be necessary once we have
new drivers -- and I very much hope nobody will try implementing these
in gnumach... So no, I don't think we will ever have a new version in
the Mach interface. The new version(s) will be for a userspace server.

(And also, as I already mentioned, I think the server side should only
implement one variant of the RPC at any given time; leaving it up to the
userspace library to invoke the right one depending on which driver is
available...)

> > Now bypassing the device_emulation interface for just one new device
> > call, would be really inconsistent and confusing;
> 
> I would see it as breaking a bad tradition.
> 
> > so passing it through the device_emulation layer instead is probably
> > preferable.
> 
> I would see this as further cementing a bad tradition.

I see your point; and normally I would almost agree... (Except that if
we really settle on a better solution for the future, it's usully better
not to mix old and new approaches, but rather rework the old stuff to
comply with the new concept.)

However, in this case we are talking about the Mach device interface,
which is scheduled to be dropped alltogether in the long term. (Well,
not entirely: I guess we will still need the basic drivers such as kbd
and maptime... But all the fancy drivers, along with the complex calls,
will hopefully die.) In consideration of this, I really think it would
be better to just do the most pragmatic thing -- which is most likely
sticking to the trodden path, rather than trying a new approach...

I'm not really set on this; but to me it looks like a new path for
directly invoking driver-specific functions would just be taking an
unnecessary risk here.

(OTOH, you looked at this code more than me; so you probably have a
better idea what it really takes...)

> > I somehow managed to temporarily forget the most important reason
> > why it makes sense to stick to whatever the Linux interface does: as
> > the actual driver we will use in the future will most likely come
> > directly from Linux, using any substantially different interface
> > would be extra effort ... So better keep close to Linux, unless
> > there is a really really good reason not to.
> 
> If we use the Linux struct sg_io_hdr in userspace, then we are
> halfways prepared for that. A few extensions learned from FreeBSD and
> Solaris would do no harm.

My hope is that once we use a modern Linux driver, we could use
*exactly* the same code in libburn; with only the final ioctl() replaced
by an RPC invocation... (Or we might even go for an ioctl() wrapper in
glibc -- not sure.)

But again, that's for the future -- not really relevant right now :-)

-antrik-