> No, I'm saying that the author of the SRA patches did the right thing
> and used the traditional BSD math library when extending the
> traditional BSD telnet utility. I am furthermore making the point
> that FreeBSD should continue to ship with a library that provides
> the `libmp' interface, r
> > So it seems to me the _use_ of a "" target symlink
> > (in all but the final path component position) is exactly
> > equivalent to the use of a "/" target symlink. When used in
> > the final path component position, you get either the symlink
> > or ENOENT. The POSIX excerpt Garrett quoted s
On Mon, 18 Jun 2001, Bakul Shah wrote:
> > NetBSD committed essentially this patch 4 years ago (as part of rev.1.23).
> > I like it, except it seems to be incompatible with POSIX.1-200x.
>
> > ... [not what "not quite" applies to]
>
> Err... not quite. Given a path like
> /
> after the sub
matsuda-san,
thanks for the very good and complete bug report. This
information is quite helpful to me. Many have complained about this
problem, but your message is the first to provide enough detail for me
to guess at the cause.
In message <[EMAIL PROTECTED]> Munehiro Matsuda writes:
:
A current world with a May 23 kernel works ok, so you may be lucky :)
> I get the following panic on a GENERIC kernel from around May 23:
>
> (copied by hand)
>
> /usr/src/sys/kern/kern_synch.c:385: sleeping with "vm" locked from
>/usr/src/sys/vm/vm_pager.c:428
> panic: sleeping process owns a
On Saturday, 16 June 2001 at 15:22:39 -0600, Chad David wrote:
> I get the following panic on a GENERIC kernel from around May 23:
>
> (copied by hand)
>
> /usr/src/sys/kern/kern_synch.c:385: sleeping with "vm" locked from
>/usr/src/sys/vm/vm_pager.c:428
> panic: sleeping process owns a mutext
>
I get the following panic on a GENERIC kernel from around May 23:
(copied by hand)
/usr/src/sys/kern/kern_synch.c:385: sleeping with "vm" locked from
/usr/src/sys/vm/vm_pager.c:428
panic: sleeping process owns a mutext
Debugger("panic")
Stopped at Debugger+0x44: pushl %ebx
db> trace
Debugger()
> < said:
>
> > Here's an example of a complication: what is the semantics of /tmp/foo/bar
> > where foo is a symlink to ""? I think the pathname resolves to
> > /tmp//bar and then to /tmp/bar, but this is surprising since foo doesn't
> > point anywhere.
>
> But this is at least consistent with
< said:
> But telnet in historic BSD didn't have sra or any other authentication
> mechanism that uses libmp. Or are you saying that we cannot change
> `historical BSD software'?
No, I'm saying that the author of the SRA patches did the right thing
and used the traditional BSD math library when
<
said:
> In anycase, I can't imagine that POSIX actually intended null
> symlinks to act in any particular way
The standard specifies precisely how pathname resolution is supposed
to behave. FreeBSD should conform to the standard, even if some of
the consequences are somewhat unexpected. (At
:< said:
:
:>> > ./foo/ .//
:>> > ./foo/bar .//bar
:>>
:>> No, because the ``resulting filename'' begins with a slash.
:
:> It seems resulting filename (pathname?) begins with "./" (not a slash).
:
:No, it doesn't. The ``resulting filename'' is "/" in the first case,
:and "/b
< said:
>> >./foo/ .//
>> >./foo/bar .//bar
>>
>> No, because the ``resulting filename'' begins with a slash.
> It seems resulting filename (pathname?) begins with "./" (not a slash).
No, it doesn't. The ``resulting filename'' is "/" in the first case,
and "/bar" in the
On Mon, Jun 18, 2001 at 13:22:10 -0400, Garrett Wollman wrote:
> < said:
>
> > Maybe it is just my bad English understanding, but it seems last two cases
> > must be
> > ./foo/ .//
> > ./foo/bar .//bar
>
> No, because the ``resulting filename'' begins with a slash.
It see
< said:
> Maybe it is just my bad English understanding, but it seems last two cases
> must be
> ./foo/ .//
> ./foo/bar .//bar
No, because the ``resulting filename'' begins with a slash.
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe fre
> NetBSD committed essentially this patch 4 years ago (as part of rev.1.23).
> I like it, except it seems to be incompatible with POSIX.1-200x.
> The bug that stat(2) on a null symlink classifies the target of the symlink
> as a directory is caused by resolving the pathname to "" and then not
> r
On Mon, Jun 18, 2001 at 11:53:59 -0400, Garrett Wollman wrote:
> < said:
>
> > NetBSD committed essentially this patch 4 years ago (as part of rev.1.23).
> > I like it, except it seems to be incompatible with POSIX.1-200x.
>
> I think I agree with your interpretation. Quoting from XBDd7, page
>
< said:
> NetBSD committed essentially this patch 4 years ago (as part of rev.1.23).
> I like it, except it seems to be incompatible with POSIX.1-200x.
I think I agree with your interpretation. Quoting from XBDd7, page
101, lines 3153ff:
# In all other cases, the system shall prefix the remain
Hi,
I'm having panic with recent pccard/pcic changes on system boot.
The system is Sony VAIO PCG-Z505V/BP.
Here's the panic message:
kernel trap 12 with interrupts disabled
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xc42ef780
fault code = supervisor
jedgar> Commenting hints.psm.0.* and hint.atkbd.0.* from /boot/device.hints
jedgar> (http://docs.freebsd.org/cgi/getmsg.cgi?fetch=84052+0+current/freebsd-current)
jedgar> works here.
I have similar problem; 'ata' bus is detected twice.
We jp.FreeBSD.org have donated TrustGuard iSV, which is 13
> In message <[EMAIL PROTECTED]>, "default013 -
> subscriptio
> ns" writes:
> > Hi, thanks for the tip, but I attempted the new instructions and got this
> > error...
> > It seemed like it went a bit farther but...
> >
> > [/usr/src/lib/libc]# make all install
> > Warning: Object directory not c
On Mon, Jun 18, 2001 at 09:17:10AM -0400, Chris Faulhaber wrote:
> >
> > Can some kind soul point me in the right direction please?
> >
>
> Commenting hints.psm.0.* and hint.atkbd.0.* from /boot/device.hints
> (http://docs.freebsd.org/cgi/getmsg.cgi?fetch=84052+0+current/freebsd-current)
> work
On Mon, Jun 18, 2001 at 02:13:37PM +0100, Josef Karthauser wrote:
> Hi,
>
> I upgraded the windows software for my laptop touchpad the other day and
> now I can't get it to work properly under FreeBSD.
>
> It appears to probe twice for some reason, and I'm not kernel savey
> enough to know how t
Le 2001-04-23, Thomas Quinot écrivait :
> deterministic fashion. It also tends to leave the mailbox locked on the
> server even after quitting. Running lockd with debugging enabled did
> not show anything that looks like an abnormal condition.
I am still seeing this problem on -CURRENT as of:
F
Hi,
I upgraded the windows software for my laptop touchpad the other day and
now I can't get it to work properly under FreeBSD.
It appears to probe twice for some reason, and I'm not kernel savey
enough to know how to fix it.
Here's the dmesg:
psm0: irq 12 on atkbdc0
psm0: mode
Hi,
>>> Mon, 18 Jun 2001 12:10:22 +0900,
>>> JINMEI Tatuya / <[EMAIL PROTECTED]> said:
jinmei> Thanks for the effort. Could you apply the following patch? The fix
jinmei> is not so serious for most users, but should be important for
jinmei> nomadic users who use IPv6 temporary addresses (for p
On Mon, 04 Jun 2001 16:48:30 +0900,
Seigo Tanimura said:
David> It would also be nice to get a timeline on the commit schedule for this.
>>> Test of 2 weeks should be enough, followed by commit in 15 June.
David> I request that this be on hold until we actually get -current Alphas
David> usab
In message <[EMAIL PROTECTED]>, Sheldon Hearn writes:
>
>
>On Sun, 17 Jun 2001 11:46:57 MST, Dima Dorfman wrote:
>
>> > If people think this is too much of a panic(8) implementation we
>> > can hide this behaviour behind a -JUSTDOIT! option.
>>
>> This is easy to do; just add an -f option to mdco
On Sun, 17 Jun 2001 11:46:57 MST, Dima Dorfman wrote:
> > If people think this is too much of a panic(8) implementation we
> > can hide this behaviour behind a -JUSTDOIT! option.
>
> This is easy to do; just add an -f option to mdconfig (which can be
> converted into an MD_FORCE flag or someth
28 matches
Mail list logo