login
Search
This is a second attempt at creating some handy symlinks in /sys/bus/pci/ between slots and devices. It addresses the following concerns from last time: - does not create superfluous 'device' link - correctly adds and removes links after hotplug ops - adds a bunch of documentation ;) It does not address Willy's concerns about not needing the functionN back-links. I kinda thought they were useful, no one else seemed to express an opinion... This patch is against linux-next, but do note that you'll need gregkh's "pci_get_dev_by_id refleak" patch: http://lkml.org/lkml/2008/8/21/492 for this patch to work properly. Thanks! /ac From: Alex Chiang <achiang@hp.com> Create convenience symlinks in sysfs, linking slots to device functions, and vice versa. These links make it easier for users to figure out which devices actually live in what slots. For example: sapphire:/sys/bus/pci/slots # ls 1 10 2 3 4 5 6 7 8 9 sapphire:/sys/bus/pci/slots # ls -l 3 total 0 -r--r--r-- 1 root root 65536 Aug 18 14:10 address lrwxrwxrwx 1 root root 0 Aug 18 14:10 function0 -> ../../../../devices/pci0000:23/0000:23:01.0 lrwxrwxrwx 1 root root 0 Aug 18 14:10 function1 -> ../../../../devices/pci0000:23/0000:23:01.1 sapphire:/sys/bus/pci/slots # ls -l 3/function0/slot lrwxrwxrwx 1 root root 0 Aug 18 14:13 3/function0/slot -> ../../../bus/pci/slots/3 The original form of this patch was written by Matthew Wilcox, but did not have links from the sysfs slots/ directory pointing back at the device functions. Cc: matthew@wil.cx Signed-off-by: Alex Chiang <achiang@hp.com> --- Documentation/ABI/testing/sysfs-bus-pci | 39 +++++++++++++++++++++++++ drivers/pci/pci-sysfs.c | 37 +++++++++++++++++++++++ drivers/pci/slot.c | 48 +++++++++++++++++++++++++++++++ 3 files changed, 124 insertions(+), 0 deletions(-) diff --git a/Documentation/ABI/testing/sysfs-bus-pci b/Documentation/ABI/testing/sysfs-bus-pci index ...
I was just explaining why I didn't create them when I did my version of this patch. I don't have an objection to adding them; they make logical It feels a bit strange to be doing this in two different files. I understand why -- you've got a slot to remove or you've got a device to remove, and in either case you have to get rid of the links. Did you try putting all the logic in one of the two files and calling it from the other? -- Matthew Wilcox Intel Open Source Technology Centre "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." --
Yes, agree about the memory usage, although I wonder what the actual overhead is. Does anyone have numbers for how much it costs to create a new symlink? I could try and figure this out but it will take a few I did actually try that at first, albeit as a single function to create links for either type of caller and another function to remove links for either type of caller. It was possible, but the looping I had to do was ugly. I could try again, and possible be smarter about detecting what was passed in... or making the interface more complicated... or at least just patching the same file and keeping the two different flavours of add/remove links. Thanks. /ac --
Almost nothing. sysfs creates these things on the fly as they are accessed, and if memory pressure on the machine happens, they are freed up properly and then created again if a user asks to see them in the tree. So don't worry about memory issues when adding new files or symlinks in sysfs, it just isn't a problem (we handle 20000 disks easily on low memory 31bit s390 systems.) thanks, greg k-h --
Great, thanks for the explanation. I've heard the "memory overhead" argument before for not wanting to create other sysfs files/links, so this will be good to debunk that bogeyman if it pops up again in the future. Did you get a chance to take a look at the documentation I wrote for these new symlinks? [I also went and documented the existing slots/ directory as well...] Was it what you had in mind? Thanks. /ac --
Yes, it looked very good. And thanks for the other documentation as well, if you want, you could split that out as a different patch and odds are Jesse could get that into the tree before 2.6.27 comes out :) thanks, greg k-h --
Hrm, given the harder line Linus has taken against "regression only" patches lately, it can probably wait another release cycle. After all, it's been un-documented since pre-git history anyway. ;) Thanks. /ac --
Documentation updates and new stand-alone drivers are ok at all times :) thanks, greg k-h --
You're clearly not hanging on every word of our Dear Leader: http://marc.info/?l=linux-kernel&m=121924636529367&w=2 -- Matthew Wilcox Intel Open Source Technology Centre "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." --
I read that, and parsed: I generally won't complain about them, but I also don't see the point. as being up to the maintainer's judgement. So in this case, it's up to Jesse :) thanks, greg k-h --
Linus seems cranky lately, no need to tempt him to flame me I think (besides I don't have any other critical stuff queued up atm; I'm definitely not going to ask him to pull just a doc update this late in the cycle). -- Jesse Barnes, Intel Open Source Technology Center --