> (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 conti
>> 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
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
> ther
On Thu, Mar 11, 2010 at 03:33:27PM +, Iain Hibbert wrote:
> > Could you show one (or more) real example(s) / senario(s)? That would
> > help to understand problems & clarify requirements...
>
> Well, a line discipline which takes serial IO and converts it into a soft
> device which inter
On Wed, Mar 10, 2010 at 10:22:40AM -0500, der Mouse wrote:
> Everything starts somewhere. I would never go near Uebayashi-san's
> devfs in any of the incarnations described so far on a production
> system. But I think it's high time someone started thinking about, and
> experimenting with, al
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
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 ov
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 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 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. The
At Fri, 12 Mar 2010 00:35:24 +0900, Masao Uebayashi 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!
I've had diskless
On Thu, Mar 11, 2010 at 10:05:28PM +, Andrew Doran 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 proper
> doesn't matter since devices are no
At Thu, 11 Mar 2010 10:22:29 +0900, Masao Uebayashi wrote:
Subject: Re: (Semi-random) thoughts on device tree structure and devfs
>
> On Thu, Mar 11, 2010 at 4:33 AM, Greg A. Woods wrote:
> > At Wed, 10 Mar 2010 08:56:36 + (GMT), Iain Hibbert
> > wrote:
> > Subject: Re: (Semi-random) thoug
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
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 p
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 can
> provide a reliable rbus-like facility to detachable buses
>> 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 neces
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) allocat
plu...@rya-online.net said:
> > We can discard the pseudo-devices concept, if need be.
> If a device has no parent, just attach it at root (similar to mainbus*),
> with parent == NULL, or even pseudo* at root, and pseudo-dev* at pseudo?
one can do so, but...
> it is not
> possible to pass config
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 the upstream bus, (2)
> >widen/
On Mar 11, 2010, at 11:40 AM, David Young wrote:
> 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 t
>> 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 sho
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
On Mon, Mar 08, 2010 at 06:33:04PM +0900, Masao Uebayashi wrote:
> > Well, first of all nothing says you can't read the whole file before
> > resolving dependencies; there's nothing inherently wrong with
> >
> > define foo: bar
> > :
> > define bar: baz
> > :
> >
> > I have no idea i
On Thu, 11 Mar 2010, Adam Hoka wrote:
> On Thu, 11 Mar 2010 18:18:54 +0100
> Joerg Sonnenberger 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 early boot or re
On Thu, 11 Mar 2010 18:18:54 +0100
Joerg Sonnenberger 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 early boot or read
> > only rootfs).
> >
> > For example: mount -t
On Thu, Mar 11, 2010 at 03:33:27PM +, Iain Hibbert wrote:
[...]
> and would also solve the (very slight) race condition, and moreover it
> would not require malloc of cfdata.
You can use a static cfdata_t, you know. The malloc'ing was a mistake
made initially and carried upon since.
--
Quen
On Wed, Mar 10, 2010 at 10:15:59AM -0500, der Mouse wrote:
> I'm a little confused, here. How can chmod and chown on /dev/wd0a do
> anything useful if /dev/wd0a just gets redirected to (say)
> /dev/default/wd0a? Removing access helps in only a few cases, because
> someone wishing to bypass the re
On Thu, Mar 11, 2010 at 06:18:54PM +0100, Joerg Sonnenberger 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 early boot or read
> > only rootfs).
> >
> > For example: mou
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 early boot or read
> only rootfs).
>
> For example: mount -t devfs /etc/devfs.db /dev
How is that different from mounting devfs and ca
On Fri, 12 Mar 2010 00:35:24 +0900
Masao Uebayashi wrote:
> On Thu, Mar 11, 2010 at 11:50 PM, Masao Uebayashi wrote:
> > On Thu, Mar 11, 2010 at 11:32 PM, Johnny Billquist wrote:
> >> I missed when Jochen wrote this, so I'll comment now.
> >> This might sound tempting, but I don't think it is a
On Thu, Mar 11, 2010 at 11:50 PM, Masao Uebayashi wrote:
> On Thu, Mar 11, 2010 at 11:32 PM, Johnny Billquist wrote:
>> I missed when Jochen wrote this, so I'll comment now.
>> This might sound tempting, but I don't think it is a good idea.
>> Keeping track of changes and trying to retain them ov
On Thu, 11 Mar 2010, Masao Uebayashi wrote:
> On Thu, Mar 11, 2010 at 6:56 PM, Iain Hibbert wrote:
> > On Thu, 11 Mar 2010, Masao Uebayashi wrote:
> >> > We can discard the pseudo-devices concept, if need be.
> >>
> >> In what sense?
> >>
> >> As I explained in the first post, pseudo device is st
First, a note - I asked a Linux person I work with why the penguins
switched from devfs to udevd. He said that it was a question of
pulling relatively complex policy issues out of the kernel into
userland, the stance being that things like "users in group pix should
be able to access any USB scann
On Thu, Mar 11, 2010 at 11:32 PM, Johnny Billquist wrote:
> I missed when Jochen wrote this, so I'll comment now.
> This might sound tempting, but I don't think it is a good idea.
> Keeping track of changes and trying to retain them over reboots is
> risky. And the mappings need to be able to hand
Masao Uebayashi wrote:
On Thu, Mar 11, 2010 at 2:49 AM, Jochen Kunz wrote:
Somthing else comes to my mind: Kernel configuration and devfs
configuration interact closely. E.g. you can give the device
enumeration order in the kernel configuration by "nailing down"
devices. Now those symbolic kern
On Thu, Mar 11, 2010 at 6:56 PM, Iain Hibbert wrote:
> On Thu, 11 Mar 2010, Masao Uebayashi wrote:
>> > We can discard the pseudo-devices concept, if need be.
>>
>> In what sense?
>>
>> As I explained in the first post, pseudo device is strict definition;
>> it has no parent in terms of physiical
On Thu, Mar 11, 2010 at 2:49 AM, Jochen Kunz wrote:
> Somthing else comes to my mind: Kernel configuration and devfs
> configuration interact closely. E.g. you can give the device
> enumeration order in the kernel configuration by "nailing down"
> devices. Now those symbolic kernel devices like co
On Thu, 11 Mar 2010, Masao Uebayashi wrote:
> > We can discard the pseudo-devices concept, if need be.
>
> In what sense?
>
> As I explained in the first post, pseudo device is strict definition;
> it has no parent in terms of physiical topology. It may have parents
> in terms of components. I'
On 3/6/2010 1:34 AM, David Young wrote:
On Wed, Mar 03, 2010 at 08:23:39AM +0200, Brad du Plessis wrote:
Hi all,
I've been seeing panics on a netbsd-4/i386 machine which appears to
be related to the reception of oversized frames:
re0: discarding oversize frame (len=8813)
re0: discarding
40 matches
Mail list logo
