Re: ioctls, etc. (was Re: [PATCH 1/4] sas: add flag for locally attached PHYs)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


-
: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux