--- Roland McGrath <[EMAIL PROTECTED]> wrote:
> > For now at least for RLIMIT_CORE I think we should just accept
> any hard
> > maximum. However, to implement core dumps would that be a core
> server
> > that actually implemented limits on core sizes and such?
>
> Yes. If the limit is zero, then
> For now at least for RLIMIT_CORE I think we should just accept any hard
> maximum. However, to implement core dumps would that be a core server
> that actually implemented limits on core sizes and such?
Yes. If the limit is zero, then you don't call the crash server at all (we
don't call it t
> I want to start a new thread for this. Below is my current patch to fix the
> I/O permission code. All of it works. However, it is broken nevertheless:
> Although the user tss is correctly (AFAICS) setup, it doesn't come
> effective: The program is killed with Illegal Instruction. I am at m
> > 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
I put your code into oskit-mach with some small changes.
Please test the code currently in CVS and send any fixes relative to that.
Thanks again,
Roland
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
Hi,
I want to start a new thread for this. Below is my current patch to fix the
I/O permission code. All of it works. However, it is broken nevertheless:
Although the user tss is correctly (AFAICS) setup, it doesn't come
effective: The program is killed with Illegal Instruction. I am at my w
> 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.
Roland McGrath <[EMAIL PROTECTED]> writes:
>> In boot, we incorrectly setup the default kernel_command_line.
>
> Eh? Isn't the kernel's name part of a real kernel command line?
This is correct. Thus, we are looking at a different bug; in the
general case, we only pass options to init when usin
>> > 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
> I have found the offending piece of code.
>
>original_real_uid = getuid();
> original_effective_uid = geteuid();
>
> #ifdef HAVE_SETRLIMIT
> /* If we are installed setuid root be careful to not drop
> core. */
> if (original_real_uid != original_effective_uid) {
On Sun, Oct 07, 2001 at 04:39:37PM -0400, Roland McGrath wrote:
(I said:)
> > BTW, the user tss does not contain such a terminator, so I will add one.
This is wrong, it's called barrier and is there. I was just confused.
> > It also should work to set the io bitmap base address to or beyond th
> On Sun, Oct 07, 2001 at 03:32:15PM -0400, Roland McGrath wrote:
> > The 0xff byte after the bitmap is a terminator byte, check your Intel book
> > vol 1, section 9.5.2.
>
> Ah, that explains it. I have seen the extra byte, and was wondering what I
> missed. I have the Intel books now (got the
> There was a problem with the output.
Well then you should have described it in your bug report!
> I think that the problem what I was seeing is that the strings are
> generally longer than 80 characters. Thus, they wrap onto the next
> line. In fact, the first module that is loaded on my sys
On Sun, Oct 07, 2001 at 03:32:15PM -0400, Roland McGrath wrote:
> The 0xff byte after the bitmap is a terminator byte, check your Intel book
> vol 1, section 9.5.2.
Ah, that explains it. I have seen the extra byte, and was wondering what I
missed. I have the Intel books now (got them today), so
>> This patch also corrects the output: I have no clue what the padding with
>> spaces was all about, however, it seems to me to be completely
>> superfluous; the output is now consistent with other messages.
>
> Was there a problem with the output, or is this an aesthetic change?
There was a p
> In boot, we incorrectly setup the default kernel_command_line.
Eh? Isn't the kernel's name part of a real kernel command line?
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
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
> I have confirmed that the following combinations, first with your code
> and then, with my new patches, work:
Thanks!
> > [subhurd] new hurd's boot -> old boot script -> old hurd
>
> Check. However, I fail to see why we even want to be compatible here;
My rationale was that one might want t
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
The 0xff byte after the bitmap is a terminator byte, check your Intel book
vol 1, section 9.5.2. So that, at least, is not the bug you thought it
was. Note that that extra byte is included in the calculation for the
segment descriptor limit (which is a limit, not a size, so it always has -1).
Y
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:
On Sun, Oct 07, 2001 at 07:59:42PM +0200, Marcus Brinkmann wrote:
> On Wed, Oct 03, 2001 at 04:53:51PM -0400, Roland McGrath wrote:
> > First, as to the kernel implementation issue. Adding a new IKOT_* flavor
> > is not really hard, and having extra flavors for machine-specific features
> > is fi
On Wed, Oct 03, 2001 at 04:53:51PM -0400, Roland McGrath wrote:
> First, as to the kernel implementation issue. Adding a new IKOT_* flavor
> is not really hard, and having extra flavors for machine-specific features
> is fine by me. But I was also thinking it might just be easiest to stick
> wit
On Sun, Oct 07, 2001 at 03:20:11PM +0200, Marcus Brinkmann wrote:
> On Sun, Oct 07, 2001 at 05:19:28AM +0200, Marcus Brinkmann wrote:
> > The reason I could not continue testing the user tss is that
> > the i386_io_port_add call can't find the device -> io_port mapping.
>
> It turns out that the
I have confirmed that the following combinations, first with your code
and then, with my new patches, work:
> new gnumach -> new hurd's serverboot -> new hurd
Check.
> new gnumach -> old hurd's serverboot -> old hurd
Check.
> old gnumach -> new hurd's serverboot -> new hurd
Check.
> new gnu
On Sun, Oct 07, 2001 at 05:19:28AM +0200, Marcus Brinkmann wrote:
> The reason I could not continue testing the user tss is that
> the i386_io_port_add call can't find the device -> io_port mapping.
It turns out that the mach_device_t address registered with io_port_create
doesn't match the mach_
33 matches
Mail list logo
