On Fri, Aug 19, 2022 at 01:52:47AM +, Taylor R Campbell wrote:
> All that said: What is the failure mode you're seeing for ihidev that
> blocks suspend?
It fails to read HID descriptor. The ihidev device remains unfunctionnal
and breaks suspend.
I thought about this workaround:
---
p...@whooppee.com (Paul Goyette) writes:
>Don't forget to deregister the device if the xxx_attach() later exits...
I think the point was to not do this, so that a failed attach doesn't
prevent the system from entering sleep mode.
Here, calling pmf_register first on attachment is then required,
> Date: Fri, 19 Aug 2022 01:22:39 +
> From: Emmanuel Dreyfus
>
> I have patches to move the pmf_device_register() earlier in xxx_attach()
> to workaround the problem in iwm(4) and ihidev(4) where I encounter the
> problem, but perhaps the problem could be worked around globaly, by not
>
On Fri, 19 Aug 2022, Emmanuel Dreyfus wrote:
Hello
When a devices fails initialization, the xxx_attach() function may exit
early, before calling pmf_device_register().
The consequence is that any attempt to put the system to sleep fail with
a "Devices without power management support: ..."
> A working devfs that can be used in all places where device nodes
> might be needed would mean that the device vnode apparatus in ffs and
> every other fs could be removed, yes,
...only if you don't mind breaking compatability.
I don't know to what extent compatability is necessary, but I
On Tue, Jun 01, 2021 at 10:08:55AM -0700, Brian Buhrow wrote:
> hello David. What I don't see in your proposal is a way of
> implementing a dynamic device filesystem.
As I already posted about once, that's irrelevant to what I'm
proposing.
A working devfs that can be used in all places
wo...@planix.ca ("Greg A. Woods") writes:
>My understanding w.r.t. the rationale FreeBSD used in deciding to remove
>the block devices was that FreeBSD never really buffered/cached by
>device in the first place. Also, according to PHK in his 2002 BSDCan
>paper about FreeBSD's /dev, "In FreeBSD
Brian Buhrow writes:
> hello David. What I don't see in your proposal is a way of
> implementing a dynamic device
> filesystem. NetBSD, and possibly OpenBSD, are the last Unix-like OS's that
> I'm aware of that
> use static special files in their filesystems to point to devices. If your
At Tue, 1 Jun 2021 14:00:50 -0400 (EDT), Mouse
wrote:
Subject: Re: Devices.
>
> Uh, maybe _you_ do. _I_ don't. For most of my chroots, I want the
> chroot to have as minimal a set of devices as still allows it to do its
> job, and in particular I do not want it to ever dynamically
At Sat, 29 May 2021 16:17:13 -0700, John Nemeth wrote:
Subject: Re: Devices.
>
> 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
> } > > bd
On Sun 30 May 2021 at 19:30:04 -0400, John Franklin wrote:
> Consider, a USB device is inserted...
> that has a mass storage block device...
> encrypted with CGD...
> hosting a partition map...
> with an LVM PV in one of the partitions...
> that contains three LVs.
>
> How many device
> When you want a device tree in a chroot, you just mount the device
> filesystem on that chroot.
Uh, maybe _you_ do. _I_ don't. For most of my chroots, I want the
chroot to have as minimal a set of devices as still allows it to do its
job, and in particular I do not want it to ever dynamically
hello David. What I don't see in your proposal is a way of
implementing a dynamic device
filesystem. NetBSD, and possibly OpenBSD, are the last Unix-like OS's that I'm
aware of that
use static special files in their filesystems to point to devices. If your
proposal was
extended with
On Sat, May 29, 2021 at 08:43:00PM -0400, Mouse 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 joined the
>> You can run devpubd. When a wedge and thus the dk* unit attaches,
>> it runs the 01-makedev hook that creates the device node in /dev.
> That's not a "mode". It's a clunky userland daemon that tries to
> make up for the fact that we don't have a devfs.
Your wording is heavily biased.
To
On May 30, 14:24, Michael van Elst wrote:
} mueller6...@twc.com ("Thomas Mueller") writes:
}
} > Where do I find the "enough dk* nodes" mode? Would it be in
} > the kernel config? I never saw it.
}
} You can run devpubd. When a wedge and thus the dk* unit attaches, it
} runs the 01-makedev
mueller6...@twc.com ("Thomas Mueller") writes:
>Where do I find the "enough dk* nodes" mode? Would it be in the kernel
>config? I never saw it.
You can run devpubd. When a wedge and thus the dk* unit attaches, it
runs the 01-makedev hook that creates the device node in /dev.
from Michael van Elst:
> mueller6...@twc.com ("Thomas Mueller") writes:
> >It's a nuisance not to be able to recognize all partitions on a
> >GPT-partitioned drive because not enough dk* nodes have been configured.
> >FreeBSD even distinguishes between USB or SCSI disks and SATA disks, and
>
mueller6...@twc.com ("Thomas Mueller") writes:
>It's a nuisance not to be able to recognize all partitions on a
>GPT-partitioned drive because not enough dk* nodes have been configured.
>FreeBSD even distinguishes between USB or SCSI disks and SATA disks, and
>between GPT partitions and
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
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
> 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
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
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
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
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
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
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
On Jun 5, 2012, at 8:42 AM, Thor Lancelot Simon wrote:
Aside from pseudodevices, do we have any devices which aren't children
of mainbus? Some ports' use of obio seems like, perhaps, a candidate for
this, but I have not started checking them all.
directly or through parents?
Not all ports
On Tue, Jun 05, 2012 at 08:52:38AM -0700, Matt Thomas wrote:
On Jun 5, 2012, at 8:42 AM, Thor Lancelot Simon wrote:
Aside from pseudodevices, do we have any devices which aren't children
of mainbus? Some ports' use of obio seems like, perhaps, a candidate for
this, but I have not
On Tue, Jun 05, 2012 at 12:03:49PM -0400, Thor Lancelot Simon wrote:
Aside from pseudodevices, do we have any devices which aren't children
of mainbus? Some ports' use of obio seems like, perhaps, a
candidate for
this, but I have not started checking them all.
directly or
On Tue, Jun 05, 2012 at 06:06:08PM +, David Holland wrote:
Does it matter? Is there a case where a driver's notion of MAXPHYS
should depend on anything other than the buses it's attached to?
I see you say buses. So I assume you're taking into account funny
constraints to do with bus
On Tue, Jun 05, 2012 at 02:14:02PM -0400, Thor Lancelot Simon wrote:
Does it matter? Is there a case where a driver's notion of MAXPHYS
should depend on anything other than the buses it's attached to?
I see you say buses. So I assume you're taking into account funny
constraints to do
On Tue, Jun 05, 2012 at 02:14:02PM -0400, Thor Lancelot Simon wrote:
On Tue, Jun 05, 2012 at 06:06:08PM +, David Holland wrote:
Does it matter? Is there a case where a driver's notion of MAXPHYS
should depend on anything other than the buses it's attached to?
I see you say buses.
35 matches
Mail list logo
