On Thu, 11 Mar 2010, Adam Hoka wrote:
On Thu, 11 Mar 2010 18:18:54 +0100
Joerg Sonnenberger jo...@britannica.bec.de wrote:
On Thu, Mar 11, 2010 at 06:12:40PM +0100, Adam Hoka wrote:
Im wondering if it would be too hack-ish to make devfs file
backed (at least optionally, in case of
On Wed, Mar 10, 2010 at 11:35:42PM +0900, Izumi Tsutsui wrote:
MI overrides of bus_space(9) and bus_dma(9) will work analogously to the
above.
- Are those overrides mandatory or optional?
They're mandatory on platforms where there is a PCI bus.
- Could you show specific examples of
This could also enable you to do
mount -t devfs /etc/devfs-bindchroot.db /var/chroot/bind/dev
for example.
I don't think a static database will cut it. What happens when
someone attaches a new USB stick and devfs generates a bunch of new
nodes? What ownership and permissions should they
On Mar 11, 2010, at 12:31 PM, David Young wrote:
On Thu, Mar 11, 2010 at 12:20:41PM -0800, Matt Thomas wrote:
On Mar 11, 2010, at 11:40 AM, David Young wrote:
Resource management:
PCI-* bridges can override bus_space_alloc(9)/bus_space_free(9)
in order to (1) allocate space from
I think the pseudo-device abstraction is unnecessary
I think it makes sense, because it allows to limit use of the
interface-attribute-less root to a minimum. There is a reason that
many/most ports use just one mainbus at root.
That doesn't make the pseudo-device abstraction necessary.
I haven't considered David's proposal, however:
On Wed, Mar 10, 2010 at 11:35:42PM +0900, Izumi Tsutsui wrote:
- How much performance impact is expected for bus_space(9) changes
on ports that use macro for access functions?
In the grand scheme of things, converting from macro to function
mo...@rodents-montreal.org said:
have pseudo0 attach at mainbus0 and then my device attach at pseudo0
If we are taking the interface attribute abstraction serious this
doesn't work easily: A device doesn't attach at a device but at
an interface attribute (which is usually provided by a device
At Thu, 11 Mar 2010 10:22:29 +0900, Masao Uebayashi uebay...@gmail.com wrote:
Subject: Re: (Semi-random) thoughts on device tree structure and devfs
On Thu, Mar 11, 2010 at 4:33 AM, Greg A. Woods wo...@planix.ca wrote:
At Wed, 10 Mar 2010 08:56:36 + (GMT), Iain Hibbert
At Fri, 12 Mar 2010 00:35:24 +0900, Masao Uebayashi uebay...@gmail.com wrote:
Subject: Re: (Semi-random) thoughts on device tree structure and devfs
Speaking of tracking state... I've found that keeping track of state
in devfsd is very wrong.
Indeed -- I do agree with that much at least!
On Thu, Mar 11, 2010 at 10:09:25PM +0100, Matthias Drochner wrote:
dyo...@pobox.com said:
PCI-* bridges can override bus_space_alloc(9)/bus_space_free(9)
in order to (1) allocate space from the upstream bus, (2)
widen/narrow its I/O- or memory-space window. Then we
On Wed, Mar 10, 2010 at 11:47:49AM +0900, Masao Uebayashi wrote:
I wonder what is the best design / implementation of devfs.
none
When you go and do it right it turns into some automount logic and a
tmpfs.
--
David A. Holland
dholl...@netbsd.org
On Thu, Mar 11, 2010 at 01:36:41AM +0900, Masao Uebayashi wrote:
Well, yes. ?But research efforts are like that. ?Robustness is pretty
much necessary for production use but not for the stage this appears to
be at.
I'm not a researcher. I'm an engineer. I like steady move
On Thu, Mar 11, 2010 at 12:58:30PM -0800, Matt Thomas wrote:
On Mar 11, 2010, at 12:31 PM, David Young wrote:
On Thu, Mar 11, 2010 at 12:20:41PM -0800, Matt Thomas wrote:
On Mar 11, 2010, at 11:40 AM, David Young wrote:
Resource management:
PCI-* bridges can override
dyo...@pobox.com said:
(1) If a bus-bridge driver is not configured in the kernel, or if its
module is unloaded, then the code is left out.
I know... but if you add this to the commonly used ppb driver
there is no way to avoid it.
(2) Do you intend for the new methods to belong to a new
On Fri, Mar 12, 2010 at 12:57:47AM +0100, Matthias Drochner wrote:
dyo...@pobox.com said:
(1) If a bus-bridge driver is not configured in the kernel, or if its
module is unloaded, then the code is left out.
I know... but if you add this to the commonly used ppb driver
there is no
have pseudo0 attach at mainbus0 [...]
I did this because I needed a struct device
That's what attach_pseudo does...
I probably could have done it that way, but it looked easier to do it
as a pseudo-bus, and for the purposes at the time, the method didn't
matter all that much.
I think it
(1) dev_t cannot go away, because a fairly fundamental guarantee in
Unix is that two files are the same if stat returns the same (st_dev,
st_ino) pair for each.
This dev_t does not have to correspond, though, to anything else in the
system.
(3) It is also necessary that device nodes continue
17 matches
Mail list logo
