from John Nemeth:
> On May 29, 22:52, David Holland wrote:
> } On Sat, May 29, 2021 at 05:41:38PM -0400, Mouse wrote:
}
> } > > For disks, which for historical reasons live in both cdevsw and
> } > > bdevsw, both entries would point at the same disk_dev.
} >
> } > I would suggest gettin
dholland-t...@netbsd.org (David Holland) writes:
>This was all based on the experience of adding discard and adding the
>dispatching for it as a first-class [bc]devsw op rather than an ioctl:
>it was a pain because it ultimately required touching _every_ driver,
>not just the ones that needed to s
> We should really get with the times and create a devfs. I know that
> there are people that disagree with this (likely including you), but
> the archaic device node system causes a lot of headaches and it's
> time that we joined the 21st century.
I am not someone who thinks that we, for any val
On Sat, May 29, 2021 at 04:17:13PM -0700, John Nemeth wrote:
> We should really get with the times and create a devfs. I
> know that there are people that disagree with this (likely including
> you), but the archaic device node system causes a lot of headaches
> and it's time that we join
On Sun, May 30, 2021 at 12:00:16AM +0200, Johnny Billquist wrote:
> On 2021-05-29 22:26, David Holland wrote:
> > There are a number of infelicities in the way we currently handle the
> > I/O plumbing for devices in the kernel. These include:
>
> [...]
>
> Just looking/thinking about the i
On May 29, 22:52, David Holland wrote:
} On Sat, May 29, 2021 at 05:41:38PM -0400, Mouse wrote:
}
} > > For disks, which for historical reasons live in both cdevsw and
} > > bdevsw, both entries would point at the same disk_dev.
} >
} > I would suggest getting rid of the bdev/cdev distinction
On Sat, May 29, 2021 at 05:41:38PM -0400, Mouse wrote:
> There is, however, one thing I think is missing in your rework
> proposal. I see nowhere to fit in a one-off driver for idiosyncratic
> hardware - or as a pseudo-device interface to idiosyncratic kernel
> code. I've personally done enou
On 2021-05-29 22:26, David Holland wrote:
There are a number of infelicities in the way we currently handle the
I/O plumbing for devices in the kernel. These include:
[...]
Just looking/thinking about the ioctl part - you say abolish it inside
the kernel. So does that mean that we keep the io
On Sat, 29 May 2021, David Holland wrote:
Anyhow, I think this architecture addresses all the problems cited.
The critical question is: what have I overlooked? There are probably
some issues I've thought about but failed to remember to discuss
above; there are also probably some issues I've
> There are a number of infelicities in the way we currently handle the
> I/O plumbing for devices in the kernel. These include: [...]
Thank you. I don't agree with all of that (which I daresay astonishes
nobody), but much of it sounds like a codification of some vague unease
that's been floati
There are a number of infelicities in the way we currently handle the
I/O plumbing for devices in the kernel. These include:
- cloning devices exist but as currently implemented violate
layering abstractions;
- every file system needs to have cutpaste vnode ops tables for
device vno
> On May 29, 2021, at 12:22 PM, Martin Husemann wrote:
>
> On Sat, May 29, 2021 at 02:03:42PM -, Christos Zoulas wrote:
>> The baroque procedure is described in the manual page of utimes(2) where
>> one would expect it :-)
>
> We should also add a command for it to fsdb(8).
>
> Martin
Don
On Sat, May 29, 2021 at 02:03:42PM -, Christos Zoulas wrote:
> The baroque procedure is described in the manual page of utimes(2) where
> one would expect it :-)
We should also add a command for it to fsdb(8).
Martin
In article <2828.1622233...@jinx.noi.kre.to>,
Robert Elz wrote:
>Date:Fri, 28 May 2021 16:49:26 +
>From:Kenny
>Message-ID:
>
>
> | I am using NetBSD 9.2 (amd64) with ZFS as file system and I have
> | not found a command to change btime for my files.
>
>Don't bo
14 matches
Mail list logo
