|
[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 |