Re: Lock of struct filedesc, file, pgrp, session and sigio

On Mon, 18 Jun 2001 19:04:31 +0900, Seigo Tanimura tanimura said: Seigo The results of build test with the latest patch are now at: Seigo http://people.FreeBSD.org/~tanimura/pg_fd/ Seigo As it is likely to take quite a while to fix alpha, I am going to Seigo update the patch every few days.

Re: syslogd and -a

On Sun, Jul 01, 2001 at 09:20:44PM -0700, Crist J. Clark wrote: Hmmm... Looks like, # syslogd -a 192.168.1.0/29 Will work and, # syslogd -a 192.168.1.1/29 Won't. That's the standard behaviour of a netmask, isn't it? The usual way to check if host h is in network/netmask n/m is

funny strlen defines in sys/alpha/alpha/alpha-gdbstub.c

Close to the top of sys/alpha/alpha/alpha-gdbstub.c i found out this, as i was randomly browsing the kernel sources today: 1 /* $FreeBSD: src/sys/alpha/alpha/alpha-gdbstub.c,v 1.11 2001/03/28 01:54:05 jhb Exp $ */ ... 130 #define strlen gdb_strlen 131 #define strcpy

Re: syslogd and -a

On Mon, Jul 02, 2001 at 09:38:42AM +0100, David Malone wrote: On Sun, Jul 01, 2001 at 09:20:44PM -0700, Crist J. Clark wrote: Hmmm... Looks like, # syslogd -a 192.168.1.0/29 Will work and, # syslogd -a 192.168.1.1/29 Won't. That's the standard behaviour of a netmask,

Re: syslogd and -a

On Mon, 2 Jul 2001 09:38:42 +0100 David Malone [EMAIL PROTECTED] wrote: On Sun, Jul 01, 2001 at 09:20:44PM -0700, Crist J. Clark wrote: Hmmm... Looks like, # syslogd -a 192.168.1.0/29 Will work and, # syslogd -a 192.168.1.1/29 Won't. That's the standard behaviour of

TIOCSCTTY

Hi! Could someone please explain why the following code snippet does not work anymore with the /dev/console argument? # ./tiocsctty /dev/console tiocsctty: ioctl(/dev/console, TIOCSCTTY): Operation not permitted Thanks, -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED]

Re: TIOCSCTTY

* Ruslan Ermilov [EMAIL PROTECTED] [010702 10:51] wrote: Hi! Could someone please explain why the following code snippet does not work anymore with the /dev/console argument? # ./tiocsctty /dev/console tiocsctty: ioctl(/dev/console, TIOCSCTTY): Operation not permitted I think LINT has

Re: unified pwutil library - thoughts?

Hey all... So, by the fact that I got _no_ replies I must surmise that either my message didn't get posted (confirmed posting with archive), or people didn't read it, or _nobody_ thinks it is a good idea ;) but if nobody thinks it is a good idea, I _think_ I would have gotten some

Re: PAM causes segfault in login(1)

Maxim Sobolev wrote: I've noticed that new PAM segfaults when I'm typing non-existing login at console login prompt. Please fix. This current, right? Did I complain? I'll sort it out. Thanks for the debug-sleuthing! Yes, please do it. Any progress (the problem is still here)?

kernel configs completely broken

The latest config(8) changes have broken kernel configs for me such that it apparently will not rewrite the ../compile/NAME/Makefile anymore and important things like subr_trap, etc.. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the

Jesus, never mind....Re: kernel configs completely broken

I somehow missed the change to sys/ARCH/compile. On Mon, 2 Jul 2001, Matthew Jacob wrote: The latest config(8) changes have broken kernel configs for me such that it apparently will not rewrite the ../compile/NAME/Makefile anymore and important things like subr_trap, etc.. -matt To

Re: syslogd and -a

On Mon, 2 Jul 2001 08:25:38 -0700 Crist J. Clark [EMAIL PROTECTED] said: cristjc That's exactly what happens in the syslogd(8) code. However, I think cristjc that should be, cristjc n = m cristjc . cristjc . cristjc . cristjc ((h m) == n) I think it should be: ((h m) == (n

** HEADS UP **: kernel compile directory change

If you use the buildkernel/installkernel method in current to build your kernels, nothing has changed and can ignore the rest of this message. If you use the classic/developers method to build your kernels, read on. You need a new config after july 1, 2001[*]. The compile directory has moved

Re: syslogd and -a

On Mon, Jul 02, 2001 at 09:38:42AM +0100, David Malone wrote: On Sun, Jul 01, 2001 at 09:20:44PM -0700, Crist J. Clark wrote: Hmmm... Looks like, # syslogd -a 192.168.1.0/29 Will work and, # syslogd -a 192.168.1.1/29 Won't. That's the standard behaviour of a netmask,

RFC: Kernel thread system nomenclature.

The time has come (now that we have a design) to assign names to the various entities that will be created when we implement the (current name) KSE code. I have already done initial work on this and have a system running with the proc structure split into 4 parts. The names of these parts

Re: syslogd and -a

On Mon, 2 Jul 2001 12:25:42 -0700 Kris Kennaway [EMAIL PROTECTED] said: kris This doesn't seem to work with IPv6. Isn't there a libc function kris which can be used to do this? Yup, there is no api for masking address ether libc nor standard. I'll commit the following patch for IPv6: Index:

Re: RFC: Kernel thread system nomenclature.

Oh what a bikeshed you've begun. :) * Julian Elischer [EMAIL PROTECTED] [010702 14:39] wrote: The time has come (now that we have a design) to assign names to the various entities that will be created when we implement the (current name) KSE code. I have already done initial work on

Re: RFC: Kernel thread system nomenclature.

On Mon, 2 Jul 2001, Alfred Perlstein wrote: Oh what a bikeshed you've begun. :) Proc, this keeps the unix convention, a task is confusing, at least to me because afaik in Linux a task is actually a thread. Keeping it as proc will also require fewer changes to the code. :) Actually this

Re: RFC: Kernel thread system nomenclature.

On Mon, 2 Jul 2001, Julian Elischer wrote: The time has come (now that we have a design) to assign names to the various entities that will be created when we implement the (current name) KSE code. I have already done initial work on this and have a system running with the proc structure

Re: RFC: Kernel thread system nomenclature.

On Mon, 2 Jul 2001, Alfred Perlstein wrote: Scheduling control block. Remove 'Process' because as far as I understand it, it's not really a process, it's a group of threads. SCB is SCSI Command Block. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe

Re: Jesus, never mind....Re: kernel configs completely broken

In message [EMAIL PROTECTED] Matthew Jacob writes: : I somehow missed the change to sys/ARCH/compile. I'm sorry that I didn't send a heads up to current. I've corrected that now. Sorry for difficulties that you've had. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe

Re: HEADS UP: ACPI update - thermal management

Hello, Here's some experience with ACPI. It does work (which is good :-) but for some reason it turns off computer (always from under X) at rather low temperatures with emergency shutdown. How could I debug ACPI to provide more details? Regards, Vladimir -- Vladimir Kushnir - [EMAIL PROTECTED]

Re: funny strlen defines in sys/alpha/alpha/alpha-gdbstub.c

On 2001-Jul-02 11:34:25 +0300, Giorgos Keramidas [EMAIL PROTECTED] wrote: 130 #define strlen gdb_strlen 131 #define strcpy gdb_strcpy Is it really necessary to do this funny thing with the #defines? I mean, why not replace the calls with gdb_XXX() ourselves and be done with it?

Re: funny strlen defines in sys/alpha/alpha/alpha-gdbstub.c

On Tue, Jul 03, 2001 at 09:04:23AM +1000, Peter Jeremy wrote: Alternatively, given the XXX comment, why not delete the local copies of str{cpy,len}() and just usr the library versions? The original reason appears to be to avoid the possibility that str{cpy,len}() are not re-entrant. The