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
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
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
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
