> > Why is this not sufficient? This is how every other shared library
> > dependency works.
>
> I was just under the impression that a stub was the right thing to do
> in this case. I am drawing this conclusion from what I have seen in
> libc. Consider msync: it returns always returns failure
Neal H Walfield <[EMAIL PROTECTED]> writes:
> > Why is this not sufficient? This is how every other shared library
> > dependency works.
>
> I was just under the impression that a stub was the right thing to do
> in this case. I am drawing this conclusion from what I have seen in
> libc. Cons
> Why is this not sufficient? This is how every other shared library
> dependency works.
I was just under the impression that a stub was the right thing to do
in this case. I am drawing this conclusion from what I have seen in
libc. Consider msync: it returns always returns failure, however,
w
> Specifically, I am interested in how an application that uses
> store_part_create will fail. If the store_part_create function is not
> available, the application will not be able to start. Roland, I
> think, is making the assumption, that all applications which depend on
> this function will
Neal H Walfield <[EMAIL PROTECTED]> writes:
> We have two scenarios: the Hurd with the parted support or without.
> The case we are looking at now is without parted support and how to
> fail gracefully.
> ...
> This is, of course, all moot. No application will use
> store_part_create directly.
>> > I was thinking this code might be triggered by a user who requested a
>> > store_part on the command line to, say, ext2fs. Is that incorrect?
>>
>> If the hurd is compiled without libparted, then the "part" store type will
>> be completely absent, and using it on the command line will get t
Roland McGrath <[EMAIL PROTECTED]> writes:
> > I was thinking this code might be triggered by a user who requested a
> > store_part on the command line to, say, ext2fs. Is that incorrect?
>
> If the hurd is compiled without libparted, then the "part" store type will
> be completely absent, and
> I was thinking this code might be triggered by a user who requested a
> store_part on the command line to, say, ext2fs. Is that incorrect?
If the hurd is compiled without libparted, then the "part" store type will
be completely absent, and using it on the command line will get the usual
error
Roland McGrath <[EMAIL PROTECTED]> writes:
> Hmm, I think I prefer the status quo. In a program that wants to use it,
> you can write an autoconf test for store_part_create, or use #pragma weak
> if you want a runtime test.
>
> If we have stub function, I think ENOSYS is the right error for it
Hmm, I think I prefer the status quo. In a program that wants to use it,
you can write an autoconf test for store_part_create, or use #pragma weak
if you want a runtime test.
If we have stub function, I think ENOSYS is the right error for it to return.
__
>> The correct solution, would appear to be to return EINVAL if libparted
>> is not available. This patch does that:
>
> I think this is almost right... but the error shouldn't be EINVAL. A
> user shouldn't get EINVAL just because he requests a feature that
> isn't installed. Perhaps EOPNOTSUPP
Neal H Walfield <[EMAIL PROTECTED]> writes:
> The correct solution, would appear to be to return EINVAL if libparted
> is not available. This patch does that:
I think this is almost right... but the error shouldn't be EINVAL. A
user shouldn't get EINVAL just because he requests a feature that
There are two ways to open a given store. The first, and the more
common way, is to hand libstore a string to parse such as:
part:4:device:hd2. The second way, is to use one of the exported
functions to open a specific type of store. Effectively, anything is
is game. Included among them are:
13 matches
Mail list logo
