Hi, I have a fix for kern/44310 at the end of my post but first some commentary: -static int bpf_movein(struct uio *, int, int, +static int bpf_movein(struct uio *, int, uint64_t, struct mbuf **, struct sockaddr *); I change mtu type because the actual argument ifp->if_mtu at the call point is uint64_t. - int len; - int hlen; - int align; + size_t len; + size_t hlen; + size_t align; There is len = uio->uio_resid assignment later in the fuction and len should be ...

I wrote [1] a layered fs (for SYSV, also ran on solaris, SMP) that would never copy files between layers (but would create directories in the top layer). This worked fine for many uses - we used it for source trees and object files. For edits it rather relied on the fact that editors (well vi anyway) doesn't write the existing file ever - but does another open(..., O_CREAT) and so would create a new file in the top layer. This fs only really had to handle vnode lookup, almost all other ops ...

On Sun, Jan 02, 2011 at 09:19:30AM -0500, matthew sporleder wrote: > > [TRYEMULROOT] > > Since it's on http://www.netbsd.org/~dholland/buglists/file.html , I'm > sure you're aware of it, but would 41678 be solved? > > http://gnats.NetBSD.org/cgi-bin/query-pr-single.pl?number=41678 Doubtful, as that behavior's inside onionfs. I don't think applying the same simplification to onionfs would result in the behavior you want there, either. (Anyhow, like I wrote in that PR, the only real ...

Has anyone ever sat down and clearly worked out the desired semantics for TRYEMULROOT? I've noted inconsistencies in the past, and because in a number of ways it's a special case of onionfs I'm somewhat concerned that there may be cases where the proper or desired behavior is unclear or ambiguous. Right now most path lookups set TRYEMULROOT. This is fine for ordinary cases (e.g. stat) -- if the object is present under the emulation root, it's found and returned; if not, the real root is tried ...

Since it's on http://www.netbsd.org/~dholland/buglists/file.html , I'm sure you're aware of it, but would 41678 be solved? http://gnats.NetBSD.org/cgi-bin/query-pr-single.pl?number=41678

On Sun, Jan 02, 2011 at 10:48:03AM +0000, David Laight wrote: > On Sun, Jan 02, 2011 at 09:17:11AM +0000, David Holland wrote: > > Because we have at least one FS that may not want paths being looked > > up to be split on '/', namely rump etfs, and arguably the most > > important simplification to VOP_LOOKUP is to make it handle one path > > component at a time, we need a way for a FS to decide how much of a > > path it wants to digest at once. > > Slightly related is something I did ...

I first saw that on my mpc85xx port but I thought it was a local bug. Then Frank reported something similar on ofppc so I committed it to see if it made his problem go away (which it did). That made me think it is a PowerPC bus_dma bug. But it still confused me since the mpc85xx does not have a cache which is coherent in regards to DMA but ofppc does have a DMA coherent cache. But if you are seeing this on non-PowerPC, I have to wonder if the problem is in the USB code itself since amd64 also ...