![]() | |||||||||||||
Messages in this thread |
Christopoh - On Tue, May 04, 2004 at 10:41:43AM +0100, Christoph Hellwig wrote: > Better than what was there, but I still don't like it. A global array > of devices is just utter crap. Every entry point from scsi already has > struct scsi_device from which we can derive the sg-specific portion easily, > and for anything else (from a quick look that seems to be only procfs > stuff which should fade out anyway) a linear search on a linked list > is okay. > > btw, why are we vmalloc()ing Sg_device? With Doug's latest version of the patch, and changing the vmalloc of Sg_device to a kmalloc, I was able to get sg to attach to 16k devices. (I'm still debugging major/minor issues, hopefully just userspace stuff.) I was trying to get rid of the sg_dev_arr, but there is no connection from a scsi_device to a Sg_device, there is only the pointer from Sg_device to scsi_device. The sg simple class class_data is set but never used (class_set_devdata is used but not class_get_devdata). We have a scsi_device class_data that could store the Sg_device, that is a bit of a hack, since it is supposed hold scsi core data, and in theory we could have multiple scsi_device class interfaces (st and any other upper level character drivers would not use this). There is no cdev private_data, similiar to the block_device gendisk private data, so we can't use that in sg_open. The other upper level char devices (st) could also use this, as well as other char drivers. I am told this is a 2.7 item. Do you think we should do anything else (besides losing the one vmalloc) here for sg in 2.6? Specifically - Do you think we should try for a cdev private_data? With only this added, we could have a global list of all Sg_devices, and not have to do a linear search on open (I don't know how bad that would be for large numbers of devices). We would still need a linear search of the list on removal (not that bad). Should we hack the scsi_device class_data to hold a Sg_device? -- Patrick Mansfield - 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-03-22 13:03 [from the cache] ©2003-2008 | |||||||||||||