mochel@xxxxxxxx said:
> This looks wrong, based on the fact that it wasn't the cdrom layer
> that created these files. They were, I believe, created by the SCSI
> cdrom layer. So, why are they being removed here, esp. since they are
> removed at a more general layer?
sullivan@xxxxxxxxxxxxxx said:
> Maybe a first good step would be to move the cdrom support completely
> up into the general layer and use the presence of a non NULL parent
> field to indicate whether the lower level driver has added support for
> driverfs. We'd have to make sure the cdrom_drverfs_dev structure is
> initialized with zeros for all of the cdrom related driver layers that
> don't support driverfs yet. Let me know what you think. I'll pull a
> patch together...
Pat,
I think the root cause of all the ugly code is that none of us knows how to
match up the partitions or other adjunct elements which belong in the class
code with the actual device, and the fact that the generic code (cdrom and
genhd) is more than just SCSI, so we're all a little wary of messing too much
with it. Are you planning to embed a driverfs parent pointer in the relevant
structures? Do you think the best approach is to do driverfs creation/removal
for everything in the generic cdrom driver? We're all a bit reticent to do a
wholesale rework of none scsi code without a clear idea of what we're supposed
to be doing.
If you give me an idea of how you are thinking of matching up the parent
pointers, I'll have a go at doing this more generally.
James
-
To unsubscribe from this list: 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
|
