Hi,
> Well, the problem is that if we decide on a solution you don't like, you
> won't be very motivated to follow it :-) That's why I'd prefer a
> solution in consensus between all involved parties, i.e. You, Samuel,
> and me.
In general, this mindfulness is surely helpful to gain co-workers.
But in this special case i would have accepted any existing solution
and be it ever so odd.
So i can live happily with any decision about the form of a newly
introduced solution.
My remorse is only about not creating an odd protrusion in the
system interface of Hurd.
------------------------------------------------------------------
About RPC definition:
------------------------------------------------------------------
> 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.
[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.
> A more interesting question is: in what direction we keep compatibility?
In any case towards userspace.
So it would be wise to design a wide parameter set for userspace
even if most of it is already dropped at the RPC.
> I don't think it's necessary to arbitrarily allow mixing old/new servers
> and clients.
If it is ensured that both sides of RPC get updated in sync,
then we have much freedom with later changing the RPC definition.
> 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?
> Of course I still consider (a) or (b) the best options :-)
We are getting in sync. :)
(a) looks like the winner.
> I'm sure you actually mean "(unsigned int)-1" -- which is only
> equivalent to 0xffffffff on machines with 32 bit int :-)
This proposal took into respect the possibility of parameter transport
as byte array, where we would have to assume a particular word legth.
One can decide for each of both. 0xffffffff would mean more than a
month of execution time for a single transaction.
The only indispensible assumption here is: sizeof(int) >= 4.
------------------------------------------------------------------
The existing gnumach functions which i want to use:
------------------------------------------------------------------
For drives attached to SCSI controllers:
int scsi_ioctl_send_command(Scsi_Device *dev, void *buffer)
with this comment about the meaning of buffer
/*
* The structure that we are passed should look like:
*
* struct sdata {
* unsigned int inlen;
* unsigned int outlen;
* unsigned char cmd[]; # However many bytes are used for cmd.
* unsigned char data[];
* };
*/
For drives connected to IDE/ATAPI controllers:
int cdrom_queue_packet_command (ide_drive_t *drive,
struct packet_command *pc)
with
struct packet_command {
unsigned char *buffer;
int buflen;
int stat;
struct atapi_request_sense *sense_data;
unsigned char c[12];
};
sense_data is equivalent to sdata.data[0:17] in case of error reply.
struct atapi_request_sense {
unsigned char error_code : 7;
unsigned char valid : 1;
byte reserved1;
unsigned char sense_key : 4;
unsigned char reserved2 : 1;
unsigned char ili : 1;
unsigned char reserved3 : 2;
byte info[4];
byte sense_len;
byte command_info[4];
byte asc;
byte ascq;
byte fru;
byte sense_key_specific[3];
};
This corresponds to SCSI specs: SPC-3 4.5.3 Fixed format sense data, Table 26.
reserved3 is in SPC-3: FILEMARK, EOM with reference to SSC-2 (i.e. tapes).
SPC allows additional sense bytes after sense_key_specific.
packet_command.c[12] is equivalent to sdata.cmd[].
The restriction to a command length of 12 is covered by MMC-6. So no
16-byte commands should occur with a CD driver.
Both have the frightening habit to determine a command's length from
its function code. This is not completely covered by SCSI specs.
(SPC-3, Table 11, Group Code values, describes an opcode 0x7F with
variable command length.)
Linux had reason to introduce a command length parameter in its
struct sg_io_hdr.
I still have to find out, how cdrom_queue_packet_command()
determines the transfer direction of payload (read or write ?).
My suspicion is that it allows the CD drive to decide.
In gnumach/linux/src/drivers/block/ide-cd.c:
static void cdrom_pc_intr (ide_drive_t *drive)
{
...
/* Read the interrupt reason and the transfer length. */
ireason = IN_BYTE (IDE_NSECTOR_REG);
...
/* The drive wants to be written to. */
if ((ireason & 3) == 0) {
...
}
/* Same drill for reading. */
else if ((ireason & 3) == 2) {
...
Linux had reason to introduce a caller defined transfer direction.
(Maybe because only the IDE driver is willing to let the drive decide.)
------------------------------------------------------------------
General design considerations:
------------------------------------------------------------------
[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.
It would solve in general the problem of reaching gnumach from hurd.
But this is actually far outside the scope of my work.
So i submit myself to what experienced Hurd developers think is best
in the current situation.
------------------------------------------------------------------
struct device_emulation_ops or not:
------------------------------------------------------------------
> Well, obviously it's not a generic device_transact() call if we use
> SG-specific parameters
That's my remorse.
> This is
> indeed a case polymorphism -- and for the reasons explained above, it's
> not useful here :-)
So we get in sync once more.
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.
(I would also question the reason for the existence of
device_emulation_ops.set_filter()
if it really only serves for networking.)
> 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.
> However, as
> this call is not going to be used for anything else, it really doesn't
> matter whether it's explicitly specific, or pretends to be generic
This should be reason enough to make it non-generic.
------------------------------------------------------------------
Linux compatibility aspects:
------------------------------------------------------------------
> 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.
When ioctl(SG_IO) gets implemented on the kernel side, then one will
have to define a fat RPC to connect it to the userspace struct which
then will be re-composed to struct sg_io_hdr on the kernel side.
So, if the decision is for fanned-out parameters, then i would
re-unify my proposed in- and out-structs to a single struct which
begins by the same members as Linux struct sg_io_hdr.
This would at least ease porting of CD userspace drivers from Linux
to Hurd.
------------------------------------------------------------------
Have a nice day :)
Thomas
