Messages in this thread | | | From | Arnd Bergmann <> | Subject | Re: driverfs problem | Date | Tue, 21 May 2002 17:52:27 +0200 |
| |
On Monday 20 May 2002 18:39, Patrick Mochel wrote:
> This is interesting. It appears that I need to do an extra dput() when > removing files to push the refcount to 0. This counters the lookup_hash() > that is done when creating the files and directories, and is analogous to > the path_release() call in sys_unlink() and sys_rmdir(). Please try the > attached patch, and let me know if it fixes the problem. Yes, all files are correctly removed and the memory freed with that patch.
> Theoretically, I believe that's possible. Al Viro has also spoken of a > per-device filesystem, which could help in that area. Althoygh, I have not > pursued either option. Though I hate to say it, there is other progress to > be made before I have a chance to seriously investigate these options. That's ok. Right now its only a potential problem for us and if it becomes a real one, I can investigate it further. My current idea is to have a device_{create,remove}_{platform,bus}_file() interface that adds files to all devices (*_platform_file) or all devices in that belong to one bus subdir (*_bus_file). They would then shared a struct inode and thus appear hard linked. The space wasted by the dentries is a lot less than what the dentries need.
> The control unit types are irrelevant at this point, as they dictate the > type of device. You want to accurately represent the physical layout of > the system. Yes, I know. Unfortunately, the physical layout is not a tree and therefore not easy to represent in a file system. The architecture is also trying hard to hide the physical layout from the OS because 99% of the time, we don't care.
> I honestly don't know how the controllers look on the s390, so I will go > off what I do know about x86 PCI SCSI contollers. You typically have a > hierarchy like: > > . > `-- controller > |-- chan0 > | |-- 0 > | |-- 1 > | |-- 2 > | `-- 3 > ... > `-- chan1 > |-- 0 > |-- 1 > |-- 2 > `-- 3 > ... > > right? (Note: naming is fictional here) I would think the layout would If it was that easy, I probably wouldn't have needed to ask ;-). The main problem is that a device can be connected to multiple control units (something vaguely like a bridge in PCI semantics) and each of these can itself be connected to multiple channel paths (i.e. connectors of the 'channel subsystem', our root bus within driverfs). The i/o driver in Linux can mostly ignore these details, because it is based on 'subchannels', which are logical connections from the channel subsystem to a single device, independent of the path(s) inbetween.
> similar, but that's only a guess. How many devices can be on a channel? > Does splitting them up like this help with the large directories? There can be 256 channel paths, each going to a control unit and each control unit can have a number of devices depending on its type, at least thousands of devices for certain types (actually, it's yet a bit more complicated than that ;-).
The total number of devices is currently limited to 65536, each device has one unique subchannel, irq (irq number equals subchannel number) and device number. [Conny, please correct me if I've been telling nonsense]
It might be possible to list the devices by their channel path if I could use symbolic links inside driverfs for devices that are accessed through multiple channel paths, but I don't think there is much to gain from that compared to the extra effort.
Thanks for your help,
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/
| |