On Sat, Sep 14, 2019 at 09:51:12AM -0700, Jason Thorpe wrote:
> >> Given the list of smart people I've seen discussing this, I'm
> >> presumably just missing something, but what?
> >
> > Loonix.
>
> Linux isn't the only system that has such a capability.
No, but I'm pretty sure it was the
On Sun, Sep 15, 2019 at 09:53:41AM -0700, Jason Thorpe wrote:
> FYI - XNU has O_SYMLINK for this. Not saying we should necessarily add it
> to NetBSD, just noting the precedent.
>
> -- thorpej
> Sent from my iPhone.
>
> > On Sep 14, 2019, at 5:06 PM, Christos Zoulas wrote:
> >
> >
>>> If you can get a file desriptor to a symlink, [...]
> There should be no way to get a fd for a symlink; if you can,
> something bad has happened.
At present, perhaps.
> Because of the way short symlinks are handled in ffs, I wouldn't be
> surprised if managing to get one let you corrupt the
[top-posting damage repaired manually]
>> If you can get a file desriptor to a symlink, it will work; I don't
>> think that we have a way to do this now.
> FYI - XNU has O_SYMLINK for this.
What operations does it support on fds open onto symlinks?
/~\ The ASCII Mouse
> On Sep 15, 2019, at 12:43 PM, Mateusz Guzik wrote:
>
> On 9/14/19, Christos Zoulas wrote:
>>
>> Comments?
>>
>> +error = vnode_to_path(kpath, MAXPATHLEN, fp->f_vnode, l, l->l_proc);
>
> What motivates this change?
>
> I think it is a little problematic in that namecache resolution
> On Sep 15, 2019, at 1:17 PM, Mouse wrote:
>
> [top-posting damage repaired manually]
>>> If you can get a file desriptor to a symlink, it will work; I don't
>>> think that we have a way to do this now.
>> FYI - XNU has O_SYMLINK for this.
>
> What operations does it support on fds open
Michael van Elst wrote:
> We have to decide if we really want to switch things to the NAME=
> syntax and allow wedge: only for compatibility.
I went for NAME= here because x86 bootloader now uses that everywhere,
and my concern was multiboot command line root options passed as is from
m...@netbsd.org (Emmanuel Dreyfus) writes:
>Michael van Elst wrote:
>> We have to decide if we really want to switch things to the NAME=
>> syntax and allow wedge: only for compatibility.
>I went for NAME= here because x86 bootloader now uses that everywhere,
>and my concern was multiboot
On Sun, Sep 15, 2019 at 03:47:32AM +0200, Emmanuel Dreyfus wrote:
> Michael van Elst wrote:
>
> > A real solution would just support the NAME=* syntax in getwedgename().
> > It might also allow for a case-insensitive match like userland. Then
> > it would just work for config, for boot
Thor Lancelot Simon wrote:
> I've never been a fan of the wedge: syntax (as was noted at the time, it
> conflicts with the syntax for specifying network filesystem servers,
> which actually broke automation I had in place); I would not mind seeing
> it go.
IMO, both wedge: and NAME= are ugly,
On 15.09.2019 20:03, Christos Zoulas wrote:
> I think it is quite reliable because all the file descriptors would be
> recently
> opened and therefore be in the cache. One would need to DoS the cache
> cause eviction. If that turns out to be false, we can make the namecache
> reliable, or
FYI - XNU has O_SYMLINK for this. Not saying we should necessarily add it to
NetBSD, just noting the precedent.
-- thorpej
Sent from my iPhone.
> On Sep 14, 2019, at 5:06 PM, Christos Zoulas wrote:
>
> If you can get a file desriptor to a symlink, it will work; I don't think
> that we have a
On 9/14/19, Christos Zoulas wrote:
>
> Comments?
>
> + error = vnode_to_path(kpath, MAXPATHLEN, fp->f_vnode, l, l->l_proc);
What motivates this change?
I think it is a little problematic in that namecache resolution is not
guaranteed to work. If the consumer does not check for failure or
On 9/15/19, Mateusz Guzik wrote:
> On 9/14/19, Christos Zoulas wrote:
>>
>> Comments?
>>
>> +error = vnode_to_path(kpath, MAXPATHLEN, fp->f_vnode, l, l->l_proc);
>
> What motivates this change?
>
> I think it is a little problematic in that namecache resolution is not
> guaranteed to work.
On 9/14/19, Mouse wrote:
>> [...], because fexecve is causing rumbles about doing significantly
>> more reverse lookups.
>
> Why is everyone so concerned about finding "the" name of an inode, or
> indeed any name for an inode? As far as I can tell there has never
> been any promise that any
> On Sep 15, 2019, at 11:03 AM, Christos Zoulas wrote:
>
> I think it is quite reliable because all the file descriptors would be
> recently
> opened and therefore be in the cache. One would need to DoS the cache
> cause eviction. If that turns out to be false, we can make the namecache
>
16 matches
Mail list logo
