Re: Heads up! config(8) changes..
On Mon, 24 May 1999, Mike Smith wrote: I would add - Improve ECP/EPP performance if possible. - Add/finish bidirectional ECP printer support. Could you also move the source for ppc out of the i386 tree into somewhere architecture independant. If its ported to new-bus then this driver should work virtually unmodified on the alpha. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up! config(8) changes..
On Mon, May 24, 1999 at 10:46:41PM -0700, Mike Smith wrote: Someone who would help me driving ppbus, yes. I didn't have enough time last months. Do you expect that the situation will improve, or do you feel you need to hand it over to a new maintainer? The situation shall improve. But I'd like to keep time to manage iic/smbus a bit more closely. What takes time is not the development, but answering to questions, track bugs, fix them... the second live of the software. I don't have time for both, especially when the whole operating system is changing very fast like it did last few months, breaking all development tools (ether/netboot, elf/aout, gdb...). I stop here :) Most of the framework is ready to work. Just some fixes and more testing are needed for the topics mentionned later (excepted ECP support which needs more work). - fix ppc probe bugs with recent mainboards I think that this needs to wait on the PnP hooks into the resource manager. If the chipset probes are killing something, I'd wager that the something in question is mentioned in the PnP data. - sync -current and -stable This would be handy, and could probably be achieved easily. - test plip in depth That'd be useful. I would add - Improve ECP/EPP performance if possible. What do you mean here? PLIP? Then yes. I was in contact with the Linux part for this. We'll have to look at there protocol choices. - Add/finish bidirectional ECP printer support. Shall not be too hard with an ECP printer. Most of the needed routines are already in the ppbus framework. But I'm afraid that it will lead to the rewrite of lpt driver, not a bad thing though. I think there is more to do with making ppbus more and more stable than bringing new capabilities to it yet. That's certainly a worthwhile perspective. What can we do to help you? Thanks. I can't afford both developments and ppbus support. Peter proposed me some help for the newbus port (removing linker_sets). I still need manpower for the support (I know this may not be the finest part of the advanture) and the plip extensions if requested by the FreeBSD community (may not be mandatory with cheaper network cards and USB...). And finally find an ECP printer around. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msm...@freebsd.org \\-- Joseph Merrick \\ msm...@cdrom.com Nicholas -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up! config(8) changes..
On Tue, May 25, 1999 at 09:54:31AM +0100, Doug Rabson wrote: Could you also move the source for ppc out of the i386 tree into somewhere architecture independant. PLEASE ask c...@freebsd.org for a repository copy when you do this. When you renamed nlpt.c to lpt.c, you just committed a new file and thus all history was lost. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up! config(8) changes..
On Thu, Apr 29, 1999 at 10:26:48PM -0700, Mike Smith wrote: In article 19990424190901.d3a791...@spinner.netplex.com.au, Peter Wemm pe...@netplex.com.au wrote: This shouldn't cause much in the way of trouble, but it will complain about old lint in your config files. That includes 'net/tty/bio/cam' mask indicators, and 'vector xxxintr' as well as some of the wierder workarounds for the poor 'options' parsing. So: things like: device sio1 at isa? tty port IO_COM2 tty irq 3 become: device sio1 at isa? port IO_COM2 irq3 What do you do about the ppc device? Formerly, it needed to be net irq ... if the plip device was going to be used, but tty irq ... otherwise. Which one did you pick? It needs to flip between one or both, but I can't raise Nicolas lately, so I'm starting to fear that we're going to need a new maintainer. That bites, given how well things were going. Someone who would help me driving ppbus, yes. I didn't have enough time last months. So, what are the next issues: - porting ppbus to newbus (especially irq managment) - fix ppc probe bugs with recent mainboards - sync -current and -stable - test plip in depth I think there is more to do with making ppbus more and more stable than bringing new capabilities to it yet. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up! config(8) changes..
What do you do about the ppc device? Formerly, it needed to be net irq ... if the plip device was going to be used, but tty irq ... otherwise. Which one did you pick? It needs to flip between one or both, but I can't raise Nicolas lately, so I'm starting to fear that we're going to need a new maintainer. That bites, given how well things were going. Someone who would help me driving ppbus, yes. I didn't have enough time last months. Do you expect that the situation will improve, or do you feel you need to hand it over to a new maintainer? So, what are the next issues: - porting ppbus to newbus (especially irq managment) Yes. - fix ppc probe bugs with recent mainboards I think that this needs to wait on the PnP hooks into the resource manager. If the chipset probes are killing something, I'd wager that the something in question is mentioned in the PnP data. - sync -current and -stable This would be handy, and could probably be achieved easily. - test plip in depth That'd be useful. I would add - Improve ECP/EPP performance if possible. - Add/finish bidirectional ECP printer support. I think there is more to do with making ppbus more and more stable than bringing new capabilities to it yet. That's certainly a worthwhile perspective. What can we do to help you? -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msm...@freebsd.org \\-- Joseph Merrick \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up! config(8) changes..
Cleaning up some old mail On Fri, 14 May 1999 21:22:55 -0700 (PDT), John Polstra j...@polstra.com said: It seems to me that all this spl hackery would be better avoided, through a userland approach that used the tun device or something similar. Some people need or prefer to have dependable bounds on the latency of their packets. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same woll...@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up! config(8) changes..
Garrett Wollman wrote: On Fri, 14 May 1999 21:22:55 -0700 (PDT), John Polstra j...@polstra.com said: It seems to me that all this spl hackery would be better avoided, through a userland approach that used the tun device or something similar. Some people need or prefer to have dependable bounds on the latency of their packets. On the lp interface?? You've got to be joking! John --- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA Self-interest is the aphrodisiac of belief. -- James V. DeLong To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up! config(8) changes..
In old mail, John Polstra j...@polstra.com wrote: In article 19990424190901.d3a791...@spinner.netplex.com.au, Peter Wemm pe...@netplex.com.au wrote: ... So: things like: device sio1 at isa? tty port IO_COM2 tty irq 3 become: device sio1 at isa? port IO_COM2 irq3 What do you do about the ppc device? Formerly, it needed to be net irq ... if the plip device was going to be used, but tty irq ... otherwise. Which one did you pick? tty was picked (see isa_compat.h). Also, support for the hack of setting net_imask = tty_imask if slip is configured went away, so slip now has the same problems as plip. I think most of these problems can be avoided by configuring (kernel) ppp. ppp sets net_imask = tty_imask, which is sufficient provided slip and plip call splimp() as required. Only cases where the masks change significantly after ppp is initialised are necessarily broken. Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up! config(8) changes..
Bruce Evans wrote: In old mail, John Polstra j...@polstra.com wrote: What do you do about the ppc device? Formerly, it needed to be net irq ... if the plip device was going to be used, but tty irq ... otherwise. Which one did you pick? tty was picked (see isa_compat.h). Also, support for the hack of setting net_imask = tty_imask if slip is configured went away, so slip now has the same problems as plip. I think most of these problems can be avoided by configuring (kernel) ppp. ppp sets net_imask = tty_imask, which is sufficient provided slip and plip call splimp() as required. Only cases where the masks change significantly after ppp is initialised are necessarily broken. It seems to me that all this spl hackery would be better avoided, through a userland approach that used the tun device or something similar. John To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: config(8) changes..
On Mon, 10 May 1999, Peter Jeremy wrote: Peter Wemm pe...@netplex.com.au wrote: If you had old vector xxxintr, it will now cause a syntax error rather than a warning. What is the new method of specifying a non-standard interrupt function? I have some code (currently on 2.x, but I was hoping to be able to move it) where I have different interrupt functions within the same driver. I could use a single interrupt handler, but it would mean either additional latency or overhead, which I'd like to avoid. Use the flags in the driver to select. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
HEADS UP: config(8) changes..
This is late, but a few hours ago, phk chopped out some old stuff from config(8) and removed some backwards compatability warnings. A summary of the changes: If you had old tty, bio, net, cam flags, these are obsolete and will now cause a syntax error rather than a warning. If you had old vector xxxintr, it will now cause a syntax error rather than a warning. Most people would have been getting these warnings for a month or so and will have taken them out already. 'config kernel root on xx0' is gone and will cause a (non-fatal) error. The old config line is mostly no longer required. I say mostly, because there are some circumstances where people used it to change the default kernel name or force a different root device to the boot device. Forcing a different root device can be done with the following (in the config file itself, or in /etc/make.conf): options ROOTDEVICE=\wd0s1e\ If you want to call your kernel something else, try this in the config file: makeoptions KERNEL=vmunix Or use add 'KERNEL=vmunix' to /etc/make.conf, or whatever. This will compile the kernel called vmunix and install it as /vmunix and deal with /vmunix.old etc. The KERNEL option has pretty much been working for some time now, although it wasn't discovered until now. What does this mean for -current users? Not a lot.. The average user can just delete the config line entirely and forget about it. The old defunct keywords need to be deleted (bio, net, tty, vector etc). It should be noted that config(8) is destined to die sooner or later and almost certainly never make it to a release branch. Removal of the port/irq/iomem/drq etc keywords is on the agenda, but it's not clear if they will go completely away since we need a way to run without loader(8) if possible. The Alpha build is (still) broken... (BTW; Don't shoot the messenger, I didn't delete it. But I do happen to think it's basically OK, apart from the loss of 'config vmunix' - that should be fairly easy to remap if a lot of people are going to be affected. Remember, even with remapping, the config lines would need an edit.) Cheers, -Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: config(8) changes..
On Monday, 10 May 1999 at 10:04:40 +0800, Peter Wemm wrote: It should be noted that config(8) is destined to die sooner or later and almost certainly never make it to a release branch. I suppose this makes it almost bearable. What's coming in its place? Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: config(8) changes..
Peter Wemm pe...@netplex.com.au wrote: If you had old vector xxxintr, it will now cause a syntax error rather than a warning. What is the new method of specifying a non-standard interrupt function? I have some code (currently on 2.x, but I was hoping to be able to move it) where I have different interrupt functions within the same driver. I could use a single interrupt handler, but it would mean either additional latency or overhead, which I'd like to avoid. Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: config(8) changes..
If you had old vector xxxintr, it will now cause a syntax error rather than a warning. What is the new method of specifying a non-standard interrupt function? I have some code (currently on 2.x, but I was hoping to be able to move it) where I have different interrupt functions within the same driver. I could use a single interrupt handler, but it would mean either additional latency or overhead, which I'd like to avoid. The driver has to know which one(s) to attach. Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Correction: HEADS UP: config(8) changes..
Peter Wemm wrote: If you had old tty, bio, net, cam flags, these are obsolete and will now cause a syntax error rather than a warning. If you had old vector xxxintr, it will now cause a syntax error rather than a warning. This is wrong, the warnings are just the same as before. 'config kernel root on xx0' is gone and will cause a (non-fatal) error. 'config kernelname' (eg: config vmunix) has been tweaked to translate it into a makeoptions KERNEL=kernelname. The old config line is mostly no longer required. I say mostly, because there are some circumstances where people used it to change the default kernel name or force a different root device to the boot device. Forcing a different root device can be done with the following (in the config file itself, or in /etc/make.conf): options ROOTDEVICE=\wd0s1e\ Corretion.. ROOTDEVNAME.. Also, should be possible to tweak a translation in for this too so that 'root on foo' gets translated into: options ROOTDEVNAME=\foo\ I haven't done it because I could think of a zillion better things to do than fight with lex/yacc. :-] (like fix the Alpha build) Cheers, -Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up! config(8) changes..
In article 19990424190901.d3a791...@spinner.netplex.com.au, Peter Wemm pe...@netplex.com.au wrote: This shouldn't cause much in the way of trouble, but it will complain about old lint in your config files. That includes 'net/tty/bio/cam' mask indicators, and 'vector xxxintr' as well as some of the wierder workarounds for the poor 'options' parsing. So: things like: device sio1 at isa? tty port IO_COM2 tty irq 3 become: device sio1 at isa? port IO_COM2 irq3 What do you do about the ppc device? Formerly, it needed to be net irq ... if the plip device was going to be used, but tty irq ... otherwise. Which one did you pick? John -- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA Self-interest is the aphrodisiac of belief. -- James V. DeLong To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up! config(8) changes..
In article 19990424190901.d3a791...@spinner.netplex.com.au, Peter Wemm pe...@netplex.com.au wrote: This shouldn't cause much in the way of trouble, but it will complain about old lint in your config files. That includes 'net/tty/bio/cam' mask indicators, and 'vector xxxintr' as well as some of the wierder workarounds for the poor 'options' parsing. So: things like: device sio1 at isa? tty port IO_COM2 tty irq 3 become: device sio1 at isa? port IO_COM2 irq3 What do you do about the ppc device? Formerly, it needed to be net irq ... if the plip device was going to be used, but tty irq ... otherwise. Which one did you pick? It needs to flip between one or both, but I can't raise Nicolas lately, so I'm starting to fear that we're going to need a new maintainer. That bites, given how well things were going. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up! config(8) changes..
- complain if a device is specified twice (eg: 2 x psm0) Does this work for pseudo-devices also (i.e. can bin/9931 get closed)? Bill To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Heads up! config(8) changes..
This shouldn't cause much in the way of trouble, but it will complain about old lint in your config files. That includes 'net/tty/bio/cam' mask indicators, and 'vector xxxintr' as well as some of the wierder workarounds for the poor 'options' parsing. So: things like: device sio1 at isa? tty port IO_COM2 tty irq 3 become: device sio1 at isa? port IO_COM2 irq3 options VM86- options VM86 options _KPOSIX_FOO=12345L - options _KPOSIX_FOO=12345L etc. These are warnings about things that have been silently ignored for a while, or I've just (hopefully) fixed. However, I don't know lex/yacc too well, so I could well have stuffed something up. If there isn't too much trouble (ha ha! I should know better than to touch config), I'll commit a set of cleaned up GENERIC / LINT files. You do not need to build a new config(8), the version numbers have not been bumped (and don't need to). Cheers, -Peter --- Forwarded Message peter 1999/04/24 11:59:20 PDT Modified files: usr.sbin/config config.h config.y lang.l main.c mkioconf.c mkmakefile.c mkoptions.c mkswapconf.c Log: More cleanups, tweaks and features. - make this work: options FOO123=456 *without quotes* - grumble (but accept) vector xxxintr, and tty/net/bio/cam flags. - complain if a device is specified twice (eg: 2 x psm0) - don't require quotes around: port IO_COM2 - recognize negative numbers. (ie: options CAM_DEBUG_UNIT=-1) - GC some more unused stuff (we don't have composite disks from config(8)). - various other nits (snprintf paranoia etc) Revision ChangesPath 1.24 +2 -12 src/usr.sbin/config/config.h 1.30 +58 -181 src/usr.sbin/config/config.y 1.19 +7 -7 src/usr.sbin/config/lang.l 1.32 +2 -2 src/usr.sbin/config/main.c 1.54 +4 -4 src/usr.sbin/config/mkioconf.c 1.41 +4 -4 src/usr.sbin/config/mkmakefile.c 1.11 +2 -2 src/usr.sbin/config/mkoptions.c 1.19 +6 -6 src/usr.sbin/config/mkswapconf.c --- End of Forwarded Message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up! config(8) changes..
On Sat, Apr 24, 1999, Peter Wemm wrote: This shouldn't cause much in the way of trouble, but it will complain about old lint in your config files. That includes 'net/tty/bio/cam' mask indicators, and 'vector xxxintr' as well as some of the wierder workarounds for the poor 'options' parsing. So: things like: device sio1 at isa? tty port IO_COM2 tty irq 3 become: device sio1 at isa? port IO_COM2 irq3 options VM86- options VM86 options _KPOSIX_FOO=12345L - options _KPOSIX_FOO=12345L etc. Excellent! Why wasn't this done before? -- Chris Costelloch...@calldei.com And on the seventh day, He exited from append mode. pgpGhVciU4sm2.pgp Description: PGP signature
Re: Heads up! config(8) changes..
Chris Costello wrote: On Sat, Apr 24, 1999, Peter Wemm wrote: This shouldn't cause much in the way of trouble, but it will complain about old lint in your config files. That includes 'net/tty/bio/cam' mask indicators, and 'vector xxxintr' as well as some of the wierder workarounds for the poor 'options' parsing. So: things like: device sio1 at isa? tty port IO_COM2 tty irq 3 become: device sio1 at isa? port IO_COM2 irq3 options VM86- options VM86 options _KPOSIX_FOO=12345L - options _KPOSIX_FOO=12345L etc. Excellent! Why wasn't this done before? Probably because the code was a nightmare.. :-) Cheers, -Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
