lkml.org 
[lkml]   [2005]   [Oct]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: ioctls, etc. (was Re: [PATCH 1/4] sas: add flag for locally attached PHYs)
Jeff Garzik wrote:
> Douglas Gilbert wrote:
>> However, the block layer is used in the context of a
>> block device (and in some cases a char device).
>> If SAS domain discovery is done from the user space, and
>> the root file system is the far side of a SAS expander,
>> there are no suitable devices, just the SAS initiator
>> (HBA) which currently we cannot address via the block layer.

> Invalid example. All of the methods listed -- request_queue, netlink,
> chrdev, sysfs, ioctl -- will work just fine when the root filesystem is
> on the far side of a SAS expander. These are just methods of
> communication, nothing more.
>
> In your example -- userspace discovery required before root filesystem
> can be found -- a program running from initrd/initramfs would create an
> SMP device node, open it, and then proceed with the discovery and
> configuration process, which in turn creates the device nodes necessary
> to mount the root filesystem.
>
> A request_queue is just a queue. You are in complete control of who are
> the producer(s) of requests, and who are consumer(s).


Since people are having such a tough time grasping the use of
request_queue without an associated block device, here is a concrete
example: drivers/block/sx8.c.

sx8 creates a queue (grep for 'oob_q') specifically for handling
discovery and configuration requests. The only requests sent to this
queue are I2O-ish management commands, never reads or writes. Since
they are management commands, these requests are NEVER associated with a
block device. Further, when sx8 discovery begins, sx8 block devices
(and associated request_queues) simply don't exist.

Although sx8 management is entirely in-kernel, one could easily imagine
how a userland interface (chrdev?) submits userspace commands into this
queue. Further, one can see how a host adapter could register one or
more queues specifically for the transit of SMP commands.

NOTE: THIS IS NOT AN ENDORSEMENT OF REQUEST QUEUES FOR SMP. I merely
wish to clear up misunderstandings about the block layer found in this
thread.

It remains an open question whether the _complexity_ of this approach is
more than is warranted for SMP. But we've departed from that question,
in this sub-thread :)

I merely illustrate that the block layer is being used _today_ for
management commands.

Jeff


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-10-22 05:57    [W:0.296 / U:0.260 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site