Please review and test: rc driver patch

Would somebody please review and test the attached patch for the rc driver? I don't have hardware to test this. It will make the rc driver to use ttymalloc(), rather than to maintain static array of struct tty. Kazu Index: rc.c ==

userconfig()

"options USERCONFIG", "options VISUAL_USERCONFIG", and "options INTRO_USERCONFIG" were removed from /sys/conf/options.i386 and options.pc98 on 12 June. Does this mean we are going to ditch userconfig()? (Or, did I miss announcement on this issue?) Kazu To Unsubscribe: send mail to [EMAIL PROT

Re: userconfig()

On Fri, Jul 13, 2001 at 08:32:18PM +0900, Kazutaka YOKOTA wrote: > "options USERCONFIG", "options VISUAL_USERCONFIG", and "options > INTRO_USERCONFIG" were removed from /sys/conf/options.i386 and > options.pc98 on 12 June. Does this mean we are going to ditch > userconfig()? I think they were di

Re: cannot print to remote printer

Garrett Wollman wrote: > > I might be wrong in many ways, but... > > > is it then mandatory that you `reset' SIGCHLD to SIG_DFL ? > > Possibly. In the general case (as specified by standards), what > happens to SIGCHLD if it was set to SIG_IGN before exec() is > ill-defined. Some systems will

Re: cannot print to remote printer

From: Terry Lambert <[EMAIL PROTECTED]> Subject: Re: cannot print to remote printer Date: Fri, Jul 13, 2001 at 10:48:53AM -0700 > Garrett Wollman wrote: > > > The new POSIX draft, at least, sanctions the automatic reset of > > SIGCHLD to SIG_DFL upon exec(). > > How does the "NOHUP" program cont

handbook typo

Hello - Under the sysctl Tuning section, the sysctl command is missing the -w option to set the values. Thanks - David Hill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message

No Subject

 

Re: handbook typo

David Hill <[EMAIL PROTECTED]> writes: Please wrap lines at 72 characters. Thanks. > Hello - > Under the sysctl Tuning section, the sysctl command is missing the > -w option to set the values. -w is deprecated in -current. I think it's best to MFC the change that makes it optional inste

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

* Seigo Tanimura <[EMAIL PROTECTED]> [010711 19:08] wrote: > The patch and the results of build test are now on the web page. > > The discussion of ktrace(2) problem does not cover the solution of > BSD/OS, so it needs updating. Here's some more commentary and a pointer to some work done. This

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

On Fri, 13 Jul 2001 04:25:04 -0500, Alfred Perlstein <[EMAIL PROTECTED]> said: Alfred> This is just about completely file locking related, Alfred> however I do have a question about PGRP locking, in Alfred> a certain part you may have to lock two pgrps, how do you Alfred> deal with deadlock? L

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

On Fri, 13 Jul 2001 19:49:25 +0900, Seigo Tanimura said: Alfred> Certain operations, such as: Alfred> kq = (struct kqueue *)fp->f_data; Alfred> should not really require that the file be locked, it's implicitly frozen Alfred> at creation time (i think) Seigo> Yes. Only one exception beats of

Re: disklabel broken again?

In message , Matthew Jacob writ es: > >Sometime in the last few days, disklabel -Brw auto seems to have stopped >working for me on alpha It used to be the thing of: >Now I get: > >dd if=/dev/zero of=/dev/da5 bs=1024k count=10 >... >disklabel -Br

Re: disklabel broken again?

In message <[EMAIL PROTECTED]>, Ian Dowse writes: >In message , Matthew Jacob wri >t >es: >>dd if=/dev/zero of=/dev/da5 bs=1024k count=10 >>... >>disklabel -Brw da5 auto >>disklabel: No space left on device > >I think this can happen when there is an

Re: disklabel broken again?

On Fri, 13 Jul 2001, Ian Dowse wrote: > In message , Matthew Jacob writ > es: > > > >Sometime in the last few days, disklabel -Brw auto seems to have stopped > >working for me on alpha It used to be the thing of: > > >Now I get: > > > >dd if=

Re: cannot print to remote printer

At 12:18 PM +0200 7/12/01, Anton Berezin wrote: >I would also propose to guard printjob.c wait calls from this sort of >error in the future; after all, it *was* an action at a distance, and >it was not strictly easy to find the culprit. Here's a patch which I think covers all the bases mentione