Messages in this thread | | | From | Arnd Bergmann <> | Subject | driverfs problems | Date | Fri, 17 May 2002 18:08:57 +0200 |
| |
Hi,
I'm trying to write a new bus driver for the s/390 channel subsystem and stumbled over a few problems.
- If I register 'struct device's for my devices and unregister them at module unload time with put_device, the memory for the d_entries is never freed because the refcount is still '3' (or '7' for directories) at the beginning of 'driverfs_unlink()'. Consequently, 'driverfs_d_delete_file()' never gets called at all. So far, I could not find the place where the refcount is incremented and not decremented again. Any idea?
- When using many devices, a lot of memory seems to be wasted by identical files. When I simulated 65536 devices, which would be the architectural limit of the channel subsystem, my ~200MB free mem were immediately filled and the out of memory handler started killing my user space programs. More investigation showed that each dummy devices needs between 3 and 4 kb on a 31 bit s390 system. That is probably not too much if you assume that people who can afford thousands of devices typically also have much RAM, but I could imagine that there is still room for improval. Would it be feasable to allocate the dentries for standard files (name/power/status plus the ones provided by architecture and bus driver) only when the parent directory is accessed?
- I'm not sure about how to name the device directories. I don't have anything like a hierarchical structure (except for something like scsi devices behind a channel device) but rather a flat list of up to 65536 devices that are accessed by a device number that was defined by the system administrator. Each device also has a control unit type, comparable to a PCI ID, and in the general case each device driver knows about one control unit type. A hypothetical system might have - one console, control unit type 0x3215, device number 0x0000 - three network devices, control unit type 0x1732, devno 0x0100 to 0x0102 - 1024 storage devices, control unit type 0x3390, devno 0x1000 to 0x13ff
I have a.t.m. three different ideas for how to structure the driverfs, in this case: a) flat listing: /root/channel/{0000,0100,0103,0102,1000-13ff} advantage: reflects the real physical layout, no policy disadvantage: difficult to parse as a human (similar to pre-devfs /dev/*), possible scalability problems when scanning through long lists in kernel
b) by control unit type: /root/channel/1732/{0100,0101,0102} /root/channel/3215/0000 /root/channel/3390/{1000-13ff} advantage: easy to find e.g. the console if you don't know the devno disadvantage: control unit type might be unknown in a few special cases, a control unit type is not really a bus but a common property of the devices
c) split device number: /root/channel/00/00 /root/channel/01/{00,01,02} /root/channel/{10,11,12,13}/{00-ff} advantage: no large directories disadvantage: does not reflect physical structure but policy
I personally favour solution b), but I want to be consistent with other architectures. Is there any other bus handling 'many' devices? How do they do it?
Arnd <>< - 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/
| |