> > Should I do commit this patch?
>
> yes please!
Committed. Thanks,
---
Izumi Tsutsui
> At 1:03 Uhr +0900 26.6.2010, Izumi Tsutsui wrote:
> >> The patch fixes the panic on my ss20 - an UP kernel makes it to multi-user,
> >> and I can log in, and access the machine from the network. There's pppoe,
> >> netatalk and samba breakage, but that may be due to version skew with the
> >> ne
> > >> the macppc and news68k zshard()'s get the actual zsc_softc * as
> > >> the (void *arg), but sparc does not.
> > >
> > >So we should make sparc zs do so.
> > >
> > >It looks multiple interrupt handlers against the same interrupt level
> > >are properly queued and handled in sparc/intr.c:ih_i
At 1:03 Uhr +0900 26.6.2010, Izumi Tsutsui wrote:
>> The patch fixes the panic on my ss20 - an UP kernel makes it to multi-user,
>> and I can log in, and access the machine from the network. There's pppoe,
>> netatalk and samba breakage, but that may be due to version skew with the
>> netbsd-4 user
On Sat, Jun 26, 2010 at 01:03:17AM +0900, Izumi Tsutsui wrote:
> > > the ss10/ss20 are the ones to test.
> > Attached are dmesg.boot from my SS20. One with serial console, the
> > other with local framebuffer console / wscons. I net-booted the machine
> > to single user mode only.
>
> Should I do
> >> the macppc and news68k zshard()'s get the actual zsc_softc * as
> >> the (void *arg), but sparc does not.
> >
> >So we should make sparc zs do so.
> >
> >It looks multiple interrupt handlers against the same interrupt level
> >are properly queued and handled in sparc/intr.c:ih_insert(), so
> >
I've committed this one. (well it's config_mountroot(9), not 8)
I wrote:
> > > > some network devices require firmware to read MAC address. if such
> > > > devices are attached before root directory is mounted, they are not
> > > > attached as ordinary network interface.
> > > :
> > > > to resol
On Fri, Jun 25, 2010 at 10:06:41AM -0400, Greg Troxel wrote:
>
> >> Have you looked at posix to see if it speaks to this? I don't think it
> >> gets specific enough to say.
I can't actually find any discussion of this (dumb) behavior anywhere
but in the bind(2) manual page. However, it looks li
On Fri, Jun 25, 2010 at 09:02:34AM -0400, Matthew Mondor wrote:
> On Fri, 25 Jun 2010 14:51:45 +0200
> Joerg Sonnenberger wrote:
>
> > On Thu, Jun 24, 2010 at 10:55:51PM -0400, Thor Simon wrote:
> > > Can anyone tell me why, exactly, we shouldn't remove bound AF_LOCAL
> > > sockets from the files
On Fri, Jun 25, 2010 at 09:32:40AM -0400, Thor Lancelot Simon wrote:
> On Fri, Jun 25, 2010 at 02:51:45PM +0200, Joerg Sonnenberger wrote:
> > On Thu, Jun 24, 2010 at 10:55:51PM -0400, Thor Simon wrote:
> > > Can anyone tell me why, exactly, we shouldn't remove bound AF_LOCAL
> > > sockets from the
Thor Simon writes:
> On Fri, Jun 25, 2010 at 08:47:49AM -0400, Greg Troxel wrote:
>>
>> Can anyone tell me why, exactly, we shouldn't remove bound AF_LOCAL
>> sockets from the filesystem on last close? The following test program
>> produces "second socket bind failed" on every system I'v
On Fri, 25 Jun 2010 08:59:18 -0400
Matthew Mondor wrote:
> However, I wrote a small test program and realized that despite
> SO_REUSEADDR this doesn't work, and indeed after checking the kernel
> code SO_REUSEADDR is ignored in the AF_LOCAL unp_bind() code.
Out of curiosity, I modified the test
On Fri, 25 Jun 2010 09:19:03 -0400
Thor Simon wrote:
> I think this is (always has been) a considerable blind spot on the part
> of BSD partisans. Sure, we're happy to gripe about persistent SysV IPC
> objects every time we have to remember how to use ipcrm, but bound AF_UNIX
> sockets have the
On Fri, Jun 25, 2010 at 02:51:45PM +0200, Joerg Sonnenberger wrote:
> On Thu, Jun 24, 2010 at 10:55:51PM -0400, Thor Simon wrote:
> > Can anyone tell me why, exactly, we shouldn't remove bound AF_LOCAL
> > sockets from the filesystem on last close?
>
> If you want to do that, wouldn't it be easier
On Fri, Jun 25, 2010 at 08:59:18AM -0400, Matthew Mondor wrote:
> On Thu, 24 Jun 2010 22:55:51 -0400
> Thor Simon wrote:
>
> > Can anyone tell me why, exactly, we shouldn't remove bound AF_LOCAL
> > sockets from the filesystem on last close? The following test program
> > produces "second socket
On Fri, Jun 25, 2010 at 06:54:16PM +0700, Robert Elz wrote:
>
> ps: my question of whether the application can do it is obviously
> intended to be rhetorical...
Except it's not. The application really _can't_ -- without poking
in the kernel, you can't even tell if it's safe to clean them up
beca
On Fri, Jun 25, 2010 at 08:47:49AM -0400, Greg Troxel wrote:
>
> Can anyone tell me why, exactly, we shouldn't remove bound AF_LOCAL
> sockets from the filesystem on last close? The following test program
> produces "second socket bind failed" on every system I've tested it on,
> and seem
On Fri, 25 Jun 2010 14:51:45 +0200
Joerg Sonnenberger wrote:
> On Thu, Jun 24, 2010 at 10:55:51PM -0400, Thor Simon wrote:
> > Can anyone tell me why, exactly, we shouldn't remove bound AF_LOCAL
> > sockets from the filesystem on last close?
>
> If you want to do that, wouldn't it be easier to j
On Thu, 24 Jun 2010 22:55:51 -0400
Thor Simon wrote:
> Can anyone tell me why, exactly, we shouldn't remove bound AF_LOCAL
> sockets from the filesystem on last close? The following test program
> produces "second socket bind failed" on every system I've tested it on,
> and seems to cover the on
On Thu, Jun 24, 2010 at 10:55:51PM -0400, Thor Simon wrote:
> Can anyone tell me why, exactly, we shouldn't remove bound AF_LOCAL
> sockets from the filesystem on last close?
If you want to do that, wouldn't it be easier to just go the Linux route
and move them into a separate (virtual) namespace
Can anyone tell me why, exactly, we shouldn't remove bound AF_LOCAL
sockets from the filesystem on last close? The following test program
produces "second socket bind failed" on every system I've tested it on,
and seems to cover the only possible use case for this "feature"...
Have you l
Date:Thu, 24 Jun 2010 22:55:51 -0400
From:Thor Simon
Message-ID: <20100625025551.ga6...@coyotepoint.com>
| Can anyone tell me why, exactly, we shouldn't remove bound AF_LOCAL
| sockets from the filesystem on last close?
I suspect the original reasoning was along
On Thu, Jun 24, 2010 at 10:55:51PM -0400, Thor Simon wrote:
> Can anyone tell me why, exactly, we shouldn't remove bound AF_LOCAL
> sockets from the filesystem on last close?
I think of a reason for that as they are completely useless with
a process attached to them anyway.
Kind regards
23 matches
Mail list logo
