On Thu, Jun 14, 2001 at 07:47:57PM +0200, Andrea Arcangeli wrote:
> On Thu, Jun 14, 2001 at 10:32:49AM -0700, Richard Henderson wrote:
> > within glibc, and (2) making these accesses slower since they
> > will be considered O_DIRECT after the change.
>
> and then read/write will return -EINVAL
On Thu, Jun 14, 2001 at 07:47:57PM +0200, Andrea Arcangeli wrote:
> On Thu, Jun 14, 2001 at 10:32:49AM -0700, Richard Henderson wrote:
> > within glibc, and (2) making these accesses slower since they
> > will be considered O_DIRECT after the change.
>
> and then read/write will return -EINVAL
On Thu, 14 Jun 2001, Richard Henderson wrote:
> Yes, I saw those. What is the effect of O_NOFOLLOW? To not
> follow symbolic links when opening the file. If you open a
> regular file, in effect nothing happens. Moreover, if these
> opens were not finding files now, the system wouldn't
On Thu, Jun 14, 2001 at 01:52:44PM -0400, Jeff Garzik wrote:
> You're missing the point -- it's a bad precedent.
>
> How many kernel forks and patches exist out there on the net?
How many of them are applied to 90% of kernels running out there? How
many of them will get merged eventually? How
Andrea Arcangeli wrote:
>
> On Thu, Jun 14, 2001 at 01:25:10PM -0400, Jeff Garzik wrote:
> > They don't hurt but it's also a bad precedent - you don't want to add a
> > ton of CONFIG_xxx to the Linus tree for stuff outside the Linus tree.
> > disagree with this patch.
>
> If tux will ever be
On Thu, Jun 14, 2001 at 10:32:49AM -0700, Richard Henderson wrote:
> within glibc, and (2) making these accesses slower since they
> will be considered O_DIRECT after the change.
and then read/write will return -EINVAL which is life-threatening.
O_DIRECT like rawio via /dev/raw imposes special
On Thu, Jun 14, 2001 at 01:25:10PM -0400, Jeff Garzik wrote:
> They don't hurt but it's also a bad precedent - you don't want to add a
> ton of CONFIG_xxx to the Linus tree for stuff outside the Linus tree.
> disagree with this patch.
If tux will ever be merged into mainline eventually I don't
On Thu, Jun 14, 2001 at 07:21:22PM +0200, Andrea Arcangeli wrote:
> Richard are you sure we can break O_NOFOLLOW and still expect the machine to
> boot?
[uses in glibc]
Yes, I saw those. What is the effect of O_NOFOLLOW? To not
follow symbolic links when opening the file. If you open a
Andrea Arcangeli wrote:
> Here the third, it registers the tux syscall at for the alpha so other
> people won't use such same syscall for something else (I didn't remove
> the #ifdefs since they don't hurt as they're undefined in mainline).
>
> diff -urN ref/arch/alpha/kernel/entry.S
On Thu, Jun 14, 2001 at 07:16:34PM +0200, Andrea Arcangeli wrote:
> I just got the email from Richard that he prefers to break O_NOFOLLOW
Richard are you sure we can break O_NOFOLLOW and still expect the machine to
boot?
./elf/cache.c: fd = open (temp_name, O_CREAT|O_WRONLY|O_TRUNC|O_NOFOLLOW,
On Thu, Jun 14, 2001 at 07:12:19PM +0200, Andrea Arcangeli wrote:
> is not definitive yet, O_DIRECTIO of tru64 is our O_NOFOLLOW so we're
> just screwed as we just need a wrapper anyways to make complex programs like
I just got the email from Richard that he prefers to break O_NOFOLLOW
than to
There are a number of changes in kernel API visisble to userspace that
are unregistered in 2.4 mainline. I recommend to merge them ASAP to
avoid generating collisions across different versions of the kernel.
I'll attach here a number of patches that should make us to return in
sync. They must be
There are a number of changes in kernel API visisble to userspace that
are unregistered in 2.4 mainline. I recommend to merge them ASAP to
avoid generating collisions across different versions of the kernel.
I'll attach here a number of patches that should make us to return in
sync. They must be
On Thu, Jun 14, 2001 at 07:12:19PM +0200, Andrea Arcangeli wrote:
is not definitive yet, O_DIRECTIO of tru64 is our O_NOFOLLOW so we're
just screwed as we just need a wrapper anyways to make complex programs like
I just got the email from Richard that he prefers to break O_NOFOLLOW
than to
On Thu, Jun 14, 2001 at 07:16:34PM +0200, Andrea Arcangeli wrote:
I just got the email from Richard that he prefers to break O_NOFOLLOW
Richard are you sure we can break O_NOFOLLOW and still expect the machine to
boot?
./elf/cache.c: fd = open (temp_name, O_CREAT|O_WRONLY|O_TRUNC|O_NOFOLLOW,
Andrea Arcangeli wrote:
Here the third, it registers the tux syscall at for the alpha so other
people won't use such same syscall for something else (I didn't remove
the #ifdefs since they don't hurt as they're undefined in mainline).
diff -urN ref/arch/alpha/kernel/entry.S
On Thu, Jun 14, 2001 at 07:21:22PM +0200, Andrea Arcangeli wrote:
Richard are you sure we can break O_NOFOLLOW and still expect the machine to
boot?
[uses in glibc]
Yes, I saw those. What is the effect of O_NOFOLLOW? To not
follow symbolic links when opening the file. If you open a
regular
On Thu, Jun 14, 2001 at 01:25:10PM -0400, Jeff Garzik wrote:
They don't hurt but it's also a bad precedent - you don't want to add a
ton of CONFIG_xxx to the Linus tree for stuff outside the Linus tree.
disagree with this patch.
If tux will ever be merged into mainline eventually I don't
On Thu, Jun 14, 2001 at 10:32:49AM -0700, Richard Henderson wrote:
within glibc, and (2) making these accesses slower since they
will be considered O_DIRECT after the change.
and then read/write will return -EINVAL which is life-threatening.
O_DIRECT like rawio via /dev/raw imposes special
Andrea Arcangeli wrote:
On Thu, Jun 14, 2001 at 01:25:10PM -0400, Jeff Garzik wrote:
They don't hurt but it's also a bad precedent - you don't want to add a
ton of CONFIG_xxx to the Linus tree for stuff outside the Linus tree.
disagree with this patch.
If tux will ever be merged into
On Thu, Jun 14, 2001 at 01:52:44PM -0400, Jeff Garzik wrote:
You're missing the point -- it's a bad precedent.
How many kernel forks and patches exist out there on the net?
How many of them are applied to 90% of kernels running out there? How
many of them will get merged eventually? How many
On Thu, 14 Jun 2001, Richard Henderson wrote:
Yes, I saw those. What is the effect of O_NOFOLLOW? To not
follow symbolic links when opening the file. If you open a
regular file, in effect nothing happens. Moreover, if these
opens were not finding files now, the system wouldn't work.
On Thu, Jun 14, 2001 at 07:47:57PM +0200, Andrea Arcangeli wrote:
On Thu, Jun 14, 2001 at 10:32:49AM -0700, Richard Henderson wrote:
within glibc, and (2) making these accesses slower since they
will be considered O_DIRECT after the change.
and then read/write will return -EINVAL which is
On Thu, Jun 14, 2001 at 07:47:57PM +0200, Andrea Arcangeli wrote:
On Thu, Jun 14, 2001 at 10:32:49AM -0700, Richard Henderson wrote:
within glibc, and (2) making these accesses slower since they
will be considered O_DIRECT after the change.
and then read/write will return -EINVAL which is
24 matches
Mail list logo
