On Thu, Jun 14, 2007 at 06:39:01PM +0100, Richard W.M. Jones wrote:
Daniel P. Berrange wrote:
>On Thu, Jun 14, 2007 at 07:16:21PM +0200, Jim Meyering wrote:
>>"Daniel P. Berrange" <berrange(a)redhat.com> wrote:
>>>>>And (4) can be done by libvirtd using ordinary POSIX calls, so no
>>>>>external library support is needed, just some work to remote those
>>>>>operations (which is mostly done).
>>>>Isn't doing #4 portably pretty tricky? There's still too much
>>>>variation, because many of the details aren't covered by POSIX.
>>>>At least for GNU df, it was -- it uses the mountlist module from gnulib:
>>>We don't need to enumerate all the mount points. The admin will simply
>>Lucky you :)
>>
>>>configure particulra directories (eg /var/lib/xen/images) as storage
>>>repositories. So we only need to be able to call statfs/statvfs on
>>>particular paths where we want to create a new image.
>>>
>>>>Of course, if your target is just Linux, then it is easier.
>>>Minimally we have to target Solaris too, since we know they already use
>>>libvirt.
>>Ok. Then this (also used by df) might help, if you ever
>>need portability to e.g., older Solaris, *BSD, AIX, HP-UX, etc.
>>
>>http://cvs.sv.gnu.org/viewcvs/gnulib/lib/fsusage.c?root=gnulib&view=markup
>
>Unfortunately we can't use that. The license is GPL, while libvirt needs
>to be LGPL :-(
I'm sure we can use it as guidance for possible problems though. I'm
quite surprised there are portability problems with statfs. Isn't it a
v7 call, didn't think there wouldn't be much that could go wrong :-)
Its worse than you thing :-)
CONFORMING TO
The Linux statfs() was inspired by the 4.4BSD one (but they do not
use the same structure).
And Solaris is different again, calling it statvfs with different structs
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules:
http://search.cpan.org/~danberr/ -=|
|=- Projects:
http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|