In message <20060627210158.GA23654@tibre.lip6.fr>,
Manuel Bouyer writes:


>> +       /* direct command to controller */
>> +       s = splbio();
>> +       while (amr_ccb_alloc(amr, &ac) != 0) {
>> +               error = tsleep(NULL, PRIBIO | PCATCH, "armmbx", hz);
>> +               if (error == EINTR)
>> +                       goto out;
>> +       }
>> 
>> That's gross. The command queueing should be reworked to guarentee slots,
>> like the other drivers. I'll have a look at that later. For now I would
>> probably single thread the path, so that we can have no more than one user
>> command active on the controller at once.
>
>This should already be the case, because no more than one process
>can have the device open at a time.

hi Manuel,

have you looked at how FreeBSD-6.1 handles this issue? I understand
the Linux ioctl() emulation in FreeBD-6.1 has been improved over and
above FreeBSD-6.0) (nevermind FreeBSD-5 and FreeBSD-4) to where it
supports the latest LSI-supplied Linux management tools via Linux
binary emulation.  Heck, I think (but I'm not sure) that even
FreeBSD-4.11 has more complete emulation than our amr(4).

[...]

>This tool can only retrieve status actually. Maybe this can be changed later,
>but I didn't find open-source tools to get the information on configuration
>(and I'm mostly interested in status report anyway :)
>
>But I can call it amrctl and implement stat as the only sub command.

OpenBSD 3.9 has open-source versions of the ioctl() struct definitions
and values required for a few additional management operations: 
	* mark a new drive as hot-spare,
	*  initiate rebuild (if the firmware didn't do it automatically),
	*  buzzer control (shut off active buzzer due to most-recent fault, but
           leave enabled for subsequent faults; or disable altogether).

OpenBSD implements these via a kernel layer for "block device control"
(and associated userland tool)d, which pretend to be device-agnostic;
the device-independent layer forwards to lower layer, an entry in each
device-specific driver.  But AFAICT< that lower layer is implemented
only for LSI Megaraid.  But you could extact those Megraid-firmware
structs and values, and add them to amrstat/amrctl.
  

>> It would be interesting to look at what OpenBSD has done in this area but
>> admittedly that's another project!
>
>Sure, and I don't think it would be appropriate for pullup in netbsd-3 :)

OTOH, updating amr{stat/ctl} to pass a couple of additional embedded
structs across the ioctl() interface to amrioctl(), and format the
results, seems just as approriate as the current amrstat.c....