Yes, but bolting on extra functionality that belongs to syscalls using sysctl
creates a rats
nest for userland in the long term, and it is not exactly cheap to maintain and
document
all the sysctl code. And with versioning you get to kill the old versions if
you want, with
sysctl you are left w
On 22.09.2019 19:09, Christos Zoulas wrote:
> On Sep 22, 6:59pm, n...@gmx.com (Kamil Rytarowski) wrote:
> -- Subject: Re: wedge device to name
>
> | Looking at the diff here, just adding f_mntfromlabel[] is a better
> | choice and it does not make too much dead code in old
On Sep 22, 6:59pm, n...@gmx.com (Kamil Rytarowski) wrote:
-- Subject: Re: wedge device to name
| Looking at the diff here, just adding f_mntfromlabel[] is a better
| choice and it does not make too much dead code in old syscall version.
|
| I propose to go for versioning here.
|
Unfortunately
On 22.09.2019 18:22, Christos Zoulas wrote:
> On Sep 22, 5:58pm, n...@gmx.com (Kamil Rytarowski) wrote:
> -- Subject: Re: wedge device to name
>
> | I understand and I know. Unfortunately (or fortunately) we will need to
> | live with the old syscall forever.
>
> Yes, but
On Sep 22, 5:58pm, n...@gmx.com (Kamil Rytarowski) wrote:
-- Subject: Re: wedge device to name
| I understand and I know. Unfortunately (or fortunately) we will need to
| live with the old syscall forever.
Yes, but cleaning the old code is obvious and simple. Untangling the
sysctl-augmented API
On 22.09.2019 17:50, Christos Zoulas wrote:
> Yes, but bolting on extra functionality that belongs to syscalls using
> sysctl creates a rats
> nest for userland in the long term, and it is not exactly cheap to
> maintain and document
> all the sysctl code. And with versioning you get to kill the o
I propose to pick sysctl, as it is already an existing interface to do
this work and it does not need to version syscalls.
Versioning syscalls costs, especially in testing older code-paths.
On 22.09.2019 17:15, Christos Zoulas wrote:
> Well, it is less natural and the programs need to so somethin
Well, it is less natural and the programs need to so something special to get
the information.
Anyway if people prefer the sysctl patch we can do that instead. OTOH it is
very instructive
to see how much work is needed to version a syscall in a single commit :-)
christos
> On Sep 22, 2019, at 1
On 22.09.2019 15:39, Christos Zoulas wrote:
> In article ,
> Christos Zoulas wrote:
>> In article ,
>> Michael van Elst wrote:
>>> chris...@astron.com (Christos Zoulas) writes:
>>>
I added that to df, but it needs root/operator in order to access the
device node to get wedge info. I als
In article ,
Christos Zoulas wrote:
>In article ,
>Michael van Elst wrote:
>>chris...@astron.com (Christos Zoulas) writes:
>>
>>>I added that to df, but it needs root/operator in order to access the
>>>device node to get wedge info. I also wrote a patch to expose the
>>>wedge info via sysctl:
>>
In article ,
Michael van Elst wrote:
>chris...@astron.com (Christos Zoulas) writes:
>
>>I added that to df, but it needs root/operator in order to access the
>>device node to get wedge info. I also wrote a patch to expose the
>>wedge info via sysctl:
>
>Alternatives ?
>
>Expose via an enhanced sta
On Thu, Sep 19, 2019 at 02:51:12AM -, Christos Zoulas wrote:
> But I am not sure if I should commit it... Here it is... Should I?
I vote for it (and mount, raidctl, whatever...)
--
Emmanuel Dreyfus
m...@netbsd.org
chris...@astron.com (Christos Zoulas) writes:
>I added that to df, but it needs root/operator in order to access the
>device node to get wedge info. I also wrote a patch to expose the
>wedge info via sysctl:
Alternatives ?
Expose via an enhanced statvfs() syscall. After all df is a user interfac
In article ,
Michael van Elst wrote:
>m...@netbsd.org (Emmanuel Dreyfus) writes:
>
>>But since almost all commands do the NAME=label to /dev/device translation,
>>you can take NAME=label as a device path.
>
>Only some NetBSD commands do. Most are old-fashioned and want file paths
>to deal with, an
On Wed, Sep 18, 2019 at 01:24:24PM -0700, John Nemeth wrote:
> We just need the device path to be the name, which it already
> is for LVMs. This is something that a devfs could do easily. :->
> More seriously, I do believe that a devfs would be a good thing.
Ah, a can of worms, open too. :
On Sep 18, 2:57pm, Michael van Elst wrote:
}
} >Is there a reason why we do not translate wedges devices to their name?
} >I mean, df and mount report about /dev/dkN, which is not very helpful
} >since it can change quickly. Reporting about NAME= seems a better idea.
}
} >In order to do it, we n
m...@netbsd.org (Emmanuel Dreyfus) writes:
>But since almost all commands do the NAME=label to /dev/device translation,
>you can take NAME=label as a device path.
Only some NetBSD commands do. Most are old-fashioned and want file paths
to deal with, and that's where the current mount output may c
On Wed, Sep 18, 2019 at 02:57:39PM -, Michael van Elst wrote:
> It's not necessarily a good idea to hide the dk devices, so that probably
> needs to be an optional output. Also because there are people parsing
> such output and expect a device path.
But since almost all commands do the NAME=la
m...@netbsd.org (Emmanuel Dreyfus) writes:
>Hello
>Is there a reason why we do not translate wedges devices to their name?
>I mean, df and mount report about /dev/dkN, which is not very helpful
>since it can change quickly. Reporting about NAME= seems a better idea.
>In order to do it, we need a
Hello
Is there a reason why we do not translate wedges devices to their name?
I mean, df and mount report about /dev/dkN, which is not very helpful
since it can change quickly. Reporting about NAME= seems a better idea.
In order to do it, we need a reverse getfsspecname(), and use it everywhere
r
20 matches
Mail list logo
