[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 3 of 4] libxl: Introduce pci_assignable_add and pci_assignable_remove
On Thu, 2012-05-10 at 17:29 +0100, George Dunlap wrote: > On 10/05/12 16:04, Ian Campbell wrote: > >>>> + spath = libxl__sprintf(gc, SYSFS_PCI_DEV"/"PCI_BDF"/driver", > >>>> + pcidev->domain, > >>>> + pcidev->bus, > >>>> + pcidev->dev, > >>>> + pcidev->func); > >>>> + if ( !lstat(spath,&st) ) { > >>>> + /* Find the canonical path to the driver. */ > >>>> + *dp = libxl__zalloc(gc, PATH_MAX); > >>> Should we be actually using fpathconf / sysconf here? > >> I don't really follow. What exactly is it you're proposing? > > PATH_MAX isn't really a constant these days, you can get the dynamic > > value for a particular filesystem from fpathconf. I honestly don't know > > how much of a concern this really is, especially given we are always > > necessarily talking to sysfs. > Ah right -- I didn't get that you were referring to PATH_MAX. The > "realpath" manpage specifies: "The resulting pathâname is stored as a > null-terminated string, up to a maximum of PATH_MAX bytes, in the buffer > pointed to by resolved_path." That's why I used PATH_MAX in the > allocation. I would hope that if the manpage says PATH_MAX, it means > PATH_MAX, and not "some other thing which you can get by running this > complicated command I haven't mentioned". :-) Yes, that's fair ;-) I think the issue might be that some systems declare PATH_MAX to be enormous (to cover all bases) and sysconf lets you use something more realistic/relevant to the actual situation. Looks like on Linux it is 4096, which I guess is ok. > OK -- I've also added a comment explaining why I'm doing what I'm doing > with slots, which I'll include when I re-post the patch. Ta! Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |