* Re: [PROPOSED] ata: Report 16/32bit PIO as best we can [not found] ` <49DDF1EB.2060200@rtr.ca> @ 2009-04-09 13:25 ` Jeff Garzik 2009-04-09 16:57 ` Mark Lord 2009-04-10 0:38 ` Douglas Gilbert [not found] ` <20090409140857.578a9146@lxorguk.ukuu.org.uk> 1 sibling, 2 replies; 8+ messages in thread From: Jeff Garzik @ 2009-04-09 13:25 UTC (permalink / raw) To: Mark Lord, Tejun Heo; +Cc: Alan Cox, linux-ide, linux-scsi, LKML Mark Lord wrote: > Alan Cox wrote: >> Something like this then ? >> >> >> The legacy old IDE API for this is a bit primitive so we try and map >> stuff >> sensibly onto it. >> >> - Add flags2 as we ran out of flags >> - Set PIO over DMA devices to report 32bit >> - Add ability to change the PIO32 settings if the controller permits it >> - Add that functionality into the sff drivers >> - Add that functionality into the VLB legacy driver >> - Turn on the 32bit PIO on the ninja32 and add support there >> >> Signed-off-by: Alan Cox <alan@linux.intel.com> > .. > > By all means go ahead with something like this, > and thanks for doing it, Alan. > > But.. these do look rather suspiciously like sysfs attrs to me. > > We didn't have a sysfs in the IDE days (so Gadi added the klunky > procfs "settings" thing for there), but we do now. > > I'm happy to update hdparm to check sysfs if that's where this > ends up, or to do almost nothing for it if we stick with the ioctls. hmmm, Tejun's storage summit presentation would be quite relevant at this juncture :) The short answer: we need a control mechanism for tasks such SATA PHY twiddling, host controller reset, host controller configuration (set/clear 32-bit I/O in this example), ... sysfs attrs are desired for this, but we've held off largely because this is all intertwined with the long term direction of "storage model", "transport protocol" and libata's eventual move away from strict SCSI dependency. I think the best place for sysfs attr attachment is an ata_transport module, something that's needed to be written for quite a while. You can see some of the eventual direction in scsi_transport_*.[ch] and raid_class.c. Eventually I hope to reach a point where the current crop of SATA+SAS controllers out in the field (e.g. mvsas) will attach to scsi_transport_sas or ata_transport, depending on controller port configuration and attached device(s). And for the sake of users' sanity, a single utility should be used to configure a SATA+SAS controller port. Requiring use of hdparm when the port is in SATA mode, and sg_* when the port is in SAS mode, is a bit annoying. Jeff ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PROPOSED] ata: Report 16/32bit PIO as best we can 2009-04-09 13:25 ` [PROPOSED] ata: Report 16/32bit PIO as best we can Jeff Garzik @ 2009-04-09 16:57 ` Mark Lord 2009-04-09 20:42 ` Jeff Garzik 2009-04-10 0:38 ` Douglas Gilbert 1 sibling, 1 reply; 8+ messages in thread From: Mark Lord @ 2009-04-09 16:57 UTC (permalink / raw) To: Jeff Garzik; +Cc: Tejun Heo, Alan Cox, linux-ide, linux-scsi, LKML Jeff Garzik wrote: > a single utility should be used to configure a SATA+SAS > controller port. Requiring use of hdparm when the port is in SATA mode, > and sg_* when the port is in SAS mode, is a bit annoying. .. That's why hdparm uses sg_* whenever possible already. -ml ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PROPOSED] ata: Report 16/32bit PIO as best we can 2009-04-09 16:57 ` Mark Lord @ 2009-04-09 20:42 ` Jeff Garzik 0 siblings, 0 replies; 8+ messages in thread From: Jeff Garzik @ 2009-04-09 20:42 UTC (permalink / raw) To: Mark Lord; +Cc: Tejun Heo, Alan Cox, linux-ide, linux-scsi, LKML Mark Lord wrote: > Jeff Garzik wrote: >> a single utility should be used to configure a SATA+SAS controller >> port. Requiring use of hdparm when the port is in SATA mode, and sg_* >> when the port is in SAS mode, is a bit annoying. > .. > > That's why hdparm uses sg_* whenever possible already. Does hdparm really call out to external applications sg_senddiag, sg_opcodes, sg_inq, sg_turs, etc.? Jeff ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PROPOSED] ata: Report 16/32bit PIO as best we can 2009-04-09 13:25 ` [PROPOSED] ata: Report 16/32bit PIO as best we can Jeff Garzik 2009-04-09 16:57 ` Mark Lord @ 2009-04-10 0:38 ` Douglas Gilbert 2009-04-10 0:47 ` Jeff Garzik 1 sibling, 1 reply; 8+ messages in thread From: Douglas Gilbert @ 2009-04-10 0:38 UTC (permalink / raw) To: Jeff Garzik; +Cc: Mark Lord, Tejun Heo, Alan Cox, linux-ide, linux-scsi, LKML Jeff Garzik wrote: > Mark Lord wrote: >> Alan Cox wrote: >>> Something like this then ? >>> >>> >>> The legacy old IDE API for this is a bit primitive so we try and map >>> stuff >>> sensibly onto it. >>> >>> - Add flags2 as we ran out of flags >>> - Set PIO over DMA devices to report 32bit >>> - Add ability to change the PIO32 settings if the controller permits it >>> - Add that functionality into the sff drivers >>> - Add that functionality into the VLB legacy driver >>> - Turn on the 32bit PIO on the ninja32 and add support there >>> >>> Signed-off-by: Alan Cox <alan@linux.intel.com> >> .. >> >> By all means go ahead with something like this, >> and thanks for doing it, Alan. >> >> But.. these do look rather suspiciously like sysfs attrs to me. >> >> We didn't have a sysfs in the IDE days (so Gadi added the klunky >> procfs "settings" thing for there), but we do now. >> >> I'm happy to update hdparm to check sysfs if that's where this >> ends up, or to do almost nothing for it if we stick with the ioctls. > > hmmm, Tejun's storage summit presentation would be quite relevant at > this juncture :) > > The short answer: we need a control mechanism for tasks such SATA PHY > twiddling, host controller reset, host controller configuration > (set/clear 32-bit I/O in this example), ... > > sysfs attrs are desired for this, but we've held off largely because > this is all intertwined with the long term direction of "storage model", > "transport protocol" and libata's eventual move away from strict SCSI > dependency. > > I think the best place for sysfs attr attachment is an ata_transport > module, something that's needed to be written for quite a while. You > can see some of the eventual direction in scsi_transport_*.[ch] and > raid_class.c. > > Eventually I hope to reach a point where the current crop of SATA+SAS > controllers out in the field (e.g. mvsas) will attach to > scsi_transport_sas or ata_transport, depending on controller port > configuration and attached device(s). And for the sake of users' > sanity, a single utility should be used to configure a SATA+SAS > controller port. Requiring use of hdparm when the port is in SATA mode, > and sg_* when the port is in SAS mode, is a bit annoying. The original question seemed to be about PATA. sysfs attributes would be one solution. Another solution is for libata to implement the SAT (ref: sat2r06.pdf at www.t10.org) specific mode page called "PATA Control" (see section 12.3.2). The latter solution may well work with FCoE, iSCSI, FC, USB, 1394 and SAS. Currently there is no SATA equivalent to that mode page. In the PATA case surprise me and choose the better solution. Getting to the host phy directly connected to a SATA disk is a particularly thorny problem and a no go area for sysfs in all but the direct connect case. For example a SATA "host" phy connected to a SATA disk attached to a SAS expander can be controlled via the SAS SMP protocol. hdparm assumes the device it is talking to is a PATA or SATA disk (with some support for the ATA part of an ATAPI device). hdparm is now capable of talking to such devices irrespective of whether the OS sees a ATA transport (PATA or SATA) or one of those other (evil) SCSI friendly transports (same list as above). My sg3_utils are lower level utilities that mostly map directly to SCSI or ATA commands. Feel free to write a utility that unifies the attributes of PATA/SATA/FC/SCSI/SAS/logical disks and OSD devices :-) As for the freestanding ata_transport idea which transport would a mvsas host adapter belong to which has one phy connected to a SATA disk, another connected to a SAS disk and a third one connected to a SAS expander with lots of SATA disks the other side of that? Doug Gilbert ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PROPOSED] ata: Report 16/32bit PIO as best we can 2009-04-10 0:38 ` Douglas Gilbert @ 2009-04-10 0:47 ` Jeff Garzik 0 siblings, 0 replies; 8+ messages in thread From: Jeff Garzik @ 2009-04-10 0:47 UTC (permalink / raw) To: dgilbert; +Cc: Mark Lord, Tejun Heo, Alan Cox, linux-ide, linux-scsi, LKML Douglas Gilbert wrote: > As for the freestanding ata_transport idea which transport > would a mvsas host adapter belong to which has one phy > connected to a SATA disk, another connected to a SAS disk and > a third one connected to a SAS expander with lots of SATA > disks the other side of that? Only the direct attach example would use ata_transport. Jeff ^ permalink raw reply [flat|nested] 8+ messages in thread
[parent not found: <20090409140857.578a9146@lxorguk.ukuu.org.uk>]
* Re: [PROPOSED] ata: Report 16/32bit PIO as best we can [not found] ` <20090409140857.578a9146@lxorguk.ukuu.org.uk> @ 2009-04-13 16:32 ` Jeff Garzik 2009-04-13 16:39 ` Alan Cox 0 siblings, 1 reply; 8+ messages in thread From: Jeff Garzik @ 2009-04-13 16:32 UTC (permalink / raw) To: Alan Cox; +Cc: Mark Lord, linux-ide, LKML, gwendal Alan Cox wrote: >> But.. these do look rather suspiciously like sysfs attrs to me. > > I'd rather any future sysfs interface actually exposed something more > meaningful. This is a legacy fixup 8) > >> We didn't have a sysfs in the IDE days (so Gadi added the klunky >> procfs "settings" thing for there), but we do now. >> >> I'm happy to update hdparm to check sysfs if that's where this >> ends up, or to do almost nothing for it if we stick with the ioctls. > > I'm not sure sysfs helps much anyway - you have to open the device file > and keep it open while accessing the sysfs nodes anyway (something huge > numbers of apps hopelessly fail to do so) FWIW... here is the sysfs work I referred to (in a message sent several days ago in this thread)... http://lwn.net/Articles/294608/ Jeff ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PROPOSED] ata: Report 16/32bit PIO as best we can 2009-04-13 16:32 ` Jeff Garzik @ 2009-04-13 16:39 ` Alan Cox 2009-04-13 16:57 ` Jeff Garzik 0 siblings, 1 reply; 8+ messages in thread From: Alan Cox @ 2009-04-13 16:39 UTC (permalink / raw) To: Jeff Garzik; +Cc: Mark Lord, linux-ide, LKML, gwendal On Mon, 13 Apr 2009 12:32:57 -0400 Jeff Garzik <jeff@garzik.org> wrote: > > I'm not sure sysfs helps much anyway - you have to open the device file > > and keep it open while accessing the sysfs nodes anyway (something huge > > numbers of apps hopelessly fail to do so) > > FWIW... here is the sysfs work I referred to (in a message sent several > days ago in this thread)... > > http://lwn.net/Articles/294608/ Which indeed shows the same problems. There is nothing to stop changes in the rest of the topology from causing me to write to the sysfs at the wrong moment and reconfigure/misconfigure a different object to the one intended. Alan ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PROPOSED] ata: Report 16/32bit PIO as best we can 2009-04-13 16:39 ` Alan Cox @ 2009-04-13 16:57 ` Jeff Garzik 0 siblings, 0 replies; 8+ messages in thread From: Jeff Garzik @ 2009-04-13 16:57 UTC (permalink / raw) To: Alan Cox; +Cc: Mark Lord, linux-ide, LKML, gwendal Alan Cox wrote: > On Mon, 13 Apr 2009 12:32:57 -0400 > Jeff Garzik <jeff@garzik.org> wrote: > >>> I'm not sure sysfs helps much anyway - you have to open the device file >>> and keep it open while accessing the sysfs nodes anyway (something huge >>> numbers of apps hopelessly fail to do so) >> FWIW... here is the sysfs work I referred to (in a message sent several >> days ago in this thread)... >> >> http://lwn.net/Articles/294608/ > > Which indeed shows the same problems. There is nothing to stop changes in > the rest of the topology from causing me to write to the sysfs at the > wrong moment and reconfigure/misconfigure a different object to the one > intended. The horse has already left the barn, on that one... Google's ata transport class is consistent with existing transport class work in the kernel. It is also consistent with recent admonitions in the osdblk thread, regarding the "one piece of data per sysfs file" rule. Personally I think a netlink-like approach to managing and controlling SAS and ATA would be better, but that's not what gets merged... Jeff ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2009-04-13 16:58 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <20090409133221.18202.63779.stgit@t61.ukuu.org.uk> [not found] ` <49DDF1EB.2060200@rtr.ca> 2009-04-09 13:25 ` [PROPOSED] ata: Report 16/32bit PIO as best we can Jeff Garzik 2009-04-09 16:57 ` Mark Lord 2009-04-09 20:42 ` Jeff Garzik 2009-04-10 0:38 ` Douglas Gilbert 2009-04-10 0:47 ` Jeff Garzik [not found] ` <20090409140857.578a9146@lxorguk.ukuu.org.uk> 2009-04-13 16:32 ` Jeff Garzik 2009-04-13 16:39 ` Alan Cox 2009-04-13 16:57 ` Jeff Garzik
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).