On Tuesday 03 November 2009 13:59, Wolfgang Grandegger wrote: > >> Any thoughts? > > So we need sysfs and the netlink property stuff. > > Either sysfs *or* netlink, but not both. OK. > > > > > Do we want the driver to build the id string? Or should the driver provide > > a couple > > of separate information, that is concated by candev.ko for the canhwid. > > > > Going throuhg the last postings I found these more or less common > > information: > > serial#, driver, channel#. > > What is "driver"? Forget this one please.
> The version string of the device driver is not a per > device property. At the moment, I just see hardware name, channel and > serial number. Hmm, doesn't /sys/class/can*/device point to the same device when it's a multi channel hardware? Then it's difficult to identify net x of device y, right? > > > Some additional information might be: firmware/hardware version. > > Does this not come automatically with the firmware interface? I've never use the firmware subsystem. When it allows querying such information, your are right. > > > But how to implement the device specific control? When the sysfs > > implementation's > > purpose in to satisfy udev, device specific control should be implemented > > through > > netlink and we should implement a generic interface for this to the driver > > layer. > > I think it is important that such device specific control should not require > > patching iproute2. > > I think we can forget the netlink support. The properties should go into > /sys/class/can*/device/, as usual. I believe there are similar use-cases > in the kernel and we should check how it's solved/implememented there. That would make things easier and every device driver can provide whatever is needed. Matthias _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
