Re: NIS with HPUX 10.20
On Thu, 28 Jan 1999 00:34:30 +0100, Mattias Pantzare wrote: Why _not_ use -C? What is the point in replacing a file with the same file? install -C will replace the file if the new file is diffrent. Aaaah, thank you. I misread the manpage description of -C and didn't notice and the files are the same... Cleared up, head back on straight. :-) Thanks, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: NIS with HPUX 10.20
On Wed, 27 Jan 1999 18:42:03 CST, Zach Heilig wrote: It does update the 'ctime' entry of ld-elf.so.1, so using 'find /usr \! -ctime 1 -print' right after make world will find all the old files. That's fine, then. I figured install -C wouldn't adjust ctime for files that hadn't changed. The 'find' works better if /usr/local and /usr/X11R6 are symlinks, or set the option to not recurse into those directories. And, 'perl' has to be checked manually. Well I tend to rebuild ports and X after ``make world'' and before the find -ctime check. /usr/include - this falls to 'find -ctime'. /usr/libdata/perl - you are better off ignoring old files in here. Someone explained how to solve for /usr/include with ``make -DCLOBBER includes'' and I have a nasty hack for perl5 that updates /usr/libdata/perl . Thanks, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: btokup() macro in sys/malloc.h
In message 199901280222.vaa14...@khavrinen.lcs.mit.edu, Garrett Wollman writes: On Wed, 27 Jan 1999 18:00:54 -0800 (PST), Archie Cobbs arc...@whistle.com said: Please do go ahead and update it.. the experts agree! I haven't seen any experts involved in this discussion yet. It's probably after bedtime down there in oz. It's been discussed before and agreed upon. -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: kern/subr_scanf array index of signed char
:Just curious.. why do you need the (int) cast? Actually, it could very well be that I don't. I didn't want to spend the time to check to see if the compiler warned on unsigned-char array indexes. When you add casts to quite warnings, please use the minium number of them. Even if it takes a little more time to test. I would much rather have the warnings than obfuscated code. -- -- 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: indent(1) and style(9) (was: btokup() macro in sys/malloc.h)
It would be nice if style(9) documented the options to give indent(1) to match the `approved' layout convections. (This would reduce the effort involved in importing large chunks of code). This is impossible, since indent(1) is buggy and out of date with both KNF and C. Well, you can do a certain amount. In fact, I use GNU indent and achieve a reasonable approximation. I see no evidence of this. vinum sources don't seem to have a single line in KNF, except accidentally. They have an indentation of 4 instead of 8, lots of per-statement comments, lots of lines longer than 80 characters, lots of block comments without `/*' and `*/' on a line by themself, ... It would be nice to import it, but it doesn't comply with style(9) :-) style(9) only applies to non-contrib'ed sources. e.g., vinum :-). Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: -Wall -Wcast-qual and SYSINIT
From my uderstanding, SYSINIT should always point to a function with a CONST argument because the argument is fixed as a constant at link/compile time. what functions don't expect a const? and why not? or am I mising something? julian To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: -Wall -Wcast-qual and SYSINIT
: :From my uderstanding, SYSINIT should always point to a function with a :CONST argument because the argument is fixed as a constant at link/compile :time. : :what functions don't expect a const? and why not? : :or am I mising something? : :julian Most of the functions do not expect a const argument, though that may simply be because they didn't bother to use const when they could have. However, I know at least the MALLOC initialization objects *can't* use const objects because the malloc initialization routine modifies the data object. I'm sure that a non-trivial number of the sysinits also modify their data objects. So we need to handle both cases. Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: indent(1) and style(9) (was: btokup() macro in sys/malloc.h)
On Thursday, 28 January 1999 at 19:19:12 +1100, Bruce Evans wrote: It would be nice if style(9) documented the options to give indent(1) to match the `approved' layout convections. (This would reduce the effort involved in importing large chunks of code). This is impossible, since indent(1) is buggy and out of date with both KNF and C. Well, you can do a certain amount. In fact, I use GNU indent and achieve a reasonable approximation. I see no evidence of this. vinum sources don't seem to have a single line in KNF, except accidentally. They have an indentation of 4 instead of 8, lots of per-statement comments, lots of lines longer than 80 characters, lots of block comments without `/*' and `*/' on a line by themself, ... Well, I call that an approximation. Sorry I have so many comments. I'll fix the individual line /* and */; it wasn't evident from style(9) that this was a requirement. It would be nice to import it, but it doesn't comply with style(9) :-) style(9) only applies to non-contrib'ed sources. e.g., vinum :-). Don't spoil a good story by sticking too closely to the facts. 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: btokup() macro in sys/malloc.h
Matt, By now we do know a GREAT deal about you from the way you behave. Trying to judge your age from that data, 16 years can certainly not be ruled out conclusively. I will make no secret of the fact that I was not at all happy with you becoming a committer, and your behaviour the last couple of days is exactly what I feared and expected would happen. Please go out and get yourself some fresh air some perspective. This is FreeBSD, not MattBSD. Poul-Henning In message 199901280641.waa96...@apollo.backplane.com, Matthew Dillon writes: : :And introduced at least one. If you were a programmer under my charge, :I'd tell you to use the warnings to fix only those bugs you are sure of :and leave the others alone. Nate, if you were a programmer under my charge you'd be heading out the door with your final paycheck. Your attitude smacks of a superiority complex that leaves a bad taste in my mouth. You don't know shit about me, so don't expect to get away with talking down to me. I'm not a fucking 16 year old. Right now, my opinion of *your* skills is rather at a low point. -Matt Matthew Dillon dil...@backplane.com -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: btokup().. STYLE(9)
+[ Matthew Dillon ]- | | :I think that style(9) should be modified to include | :Parenthesis may be used to improve the readbility of complex | :expressions even if not strictly required. | :instead of the stupid phrase presently there. | :also: | :Braces around code blocks should be allowable even when not strictly | :needed, for the purpose of readbility. | : | :The aim is to produce readble maintainable code, not to save bytes in | :sourcecode! | | I agree completely. I've already gotten into the habit of added | braces when conditonal expressions exceed one line, even though there | may be only one statement. Otherwise the code is just too unreadable. Is there an ident style for (x)emacs to enforce/promote this style? A set of macros for the *macs family that conforms to whatever style(9) is for that day would be pretty neat. I don't know about coral et. al or about how extensible they are but, gurus for those other editors could also contribute configs for a port? Just a thought. -- Totally Holistic Enterprises Internet| P:+61 7 3870 0066 | Andrew The Internet (Aust) Pty Ltd | F:+61 7 3870 4477 | Milton ACN: 082 081 472 | M:+61 416 022 411 |72 Col .Sig PO Box 837 Indooroopilly QLD 4068|a...@theinternet.com.au|Specialist To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: indent(1) and style(9) (was: btokup() macro in sys/malloc.h)
On Thu, Jan 28, 1999 at 06:05:37PM +1030, a little birdie told me
that Greg Lehey remarked
On Thursday, 28 January 1999 at 14:16:25 +1100, Bruce Evans wrote:
It would be nice if style(9) documented the options to give indent(1)
to match the `approved' layout convections. (This would reduce the
effort involved in importing large chunks of code).
This is impossible, since indent(1) is buggy and out of date with both
KNF and C.
Well, you can do a certain amount. In fact, I use GNU indent and
achieve a reasonable approximation. It would be nice to import it,
but it doesn't comply with style(9) :-)
indent(1) is EVIL! :)
I just recently (~month.5) had to completely reformat a mid-sized program
(~70k lines), and I had to rereformat the whole thing after indent got
done with it. It couldn't even handle:
}
else /* comment */
{
It would extend the comment over the ENTIRE following code block until it
hit another comment to end it.
Sorry, I still get twitchy when the word 'indent' is said...
---
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
| Matthew Fuller http://www.over-yonder.net/~fullermd |
* fulle...@futuresouth.com fulle...@over-yonder.net *
| UNIX Systems Administrator Specializing in FreeBSD |
* FutureSouth Communications ISPHelp ISP Consulting *
| The only reason I'm burning my candle at both ends, |
*is because I haven't figured out how to light the*
| middle yet |
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: btokup() macro in sys/malloc.h
On Thu, 28 Jan 1999, John Birrell wrote: Nate Williams wrote: Anyway, if we're going to -Wall'ify the kernel (as we should) then we need to update sytle(9) to reflect that. In fact, style(9) should say: If at all possible, your code should compile without warnings when the gcc -Wall flag is given. I disagree. As has been shown many times in the past (and I suspect the down-under constituent will show that at least a couple of the I think you must mean the Sydney-down-under constituent. There *is* a difference. 8-) 'warnings' fixes will be wrong and hide bogus code), making -Wall a goal causes people to cover up bad code with bad casts and such. '-Wall' is *NOT* a good design goal. Fixing warnings with bad casts is a problem, sure, but asking people to write code without casts (if possible) that will compile cleanly with -Wall is a reasonable thing to ask IMO. In my experience, the resulting code tends to be more portable across architectures with different pointer/long sizes and endian-ness. Just my 0.02, and I hate style(9) anyway. In cases, -Wall is bogus anyway. Here's one: foo.c:89: warning: char format, void arg (arg 2) void *region; printf(mem open failed: %s\n, region); According to standards, a void pointer may be freely used instead of any other type of pointer, both as an lvalue and to assign to the other pointer. Printf(), hence, wouldn't see a difference (of course). Gcc should not complain about various void pointer things like this. -- John Birrell - j...@cimlogic.com.au; j...@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message Brian Feldman_ __ ___ ___ ___ gr...@unixhelp.org _ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: btokup() macro in sys/malloc.h
On Wed, 27 Jan 1999, Matthew Dillon wrote: : then we need to update sytle(9) to reflect that. : : In fact, style(9) should say: : : If at all possible, your code should compile without warnings : when the gcc -Wall flag is given. : :I disagree. As has been shown many times in the past (and I suspect the :down-under constituent will show that at least a couple of the :'warnings' fixes will be wrong and hide bogus code), making -Wall a goal :causes people to cover up bad code with bad casts and such. : :'-Wall' is *NOT* a good design goal. Nonsense. -Wall does *NOT* contribute to a bad programmer programming badly, and I found at least three fairly serious mistakes when I turned it on. I mean, come on... by your argument the compiler might as well give up and not bother warning you about anything! And for the exact antithesis of silence, TenDRA has the most wonderful warnings, and it's a great free linter (but does its job better than standard lint), while producing as good code as GCC most of the time. That takes not into account once when I ran into some glaring bugs in the compilation, but at least the warnings were correct :) -Matt Matthew Dillon dil...@backplane.com :Nate : :To Unsubscribe: send mail to majord...@freebsd.org :with unsubscribe freebsd-current in the body of the message : To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message Brian Feldman_ __ ___ ___ ___ gr...@unixhelp.org _ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/i386/eisa ahb.c
How Mr. ignoromous Nate could construe this to mean that I was trying to brush something under the rug is beyond me. As I said to Julian, I probably shouldn't have made the committ, but the fact is that I not only left the module on my hotlist, I also immediately brought the potential problem to the attention of the entire list and thence, I think this whole tangled thread can probably be summed up thusly: There will always be those remarking from the sidelines about any change which goes into the FreeBSD source tree, and I do mean ANY change, the amount of commentary usually in inverse proportion to the importance of the change. This is just a given. It's also a given that some of these people will have far less clue than others and even those who have a clue will often express their comments in such a way as to come across as criticising or carping, even though they may not have meant to. There are a lot of engineers here and human interaction is rarely their strong suit. In any case, rather than getting into a protracted furball with each and every commentator and perhaps using inappropriate language in a public mailing list in the process, you've gotta do what pro golfers and ballplayers do - learn to ignore the crowd when it hasn't got anything useful to say. Any other strategy will, eventually, have you charging around the crowd, waving your golf club and slobbering maniacally - not really the kind of public image you want to be cultivating here. :-) - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: btokup() macro in sys/malloc.h
:Matt, : :By now we do know a GREAT deal about you from the way you behave. : :Trying to judge your age from that data, 16 years can certainly not :be ruled out conclusively. : :I will make no secret of the fact that I was not at all happy with :you becoming a committer, and your behaviour the last couple of :days is exactly what I feared and expected would happen. : :Please go out and get yourself some fresh air some perspective. : :This is FreeBSD, not MattBSD. : :Poul-Henning Behavior? Oh, you mean spending 8 hours getting -Wall to work? Or do you mean the new swapper? Or the huge amount of work we did to solve the dirty cache vm_page_t problem? Perhaps it was the discussion about DOS attacks against the system and why load-average-based algorithms don't work well. Lets see, what else is in my archive. Gee, looks like helpful posts for the most part! Could it be cpdup that you don't like? Maybe the scheduler discussions grated on your nerves? The diskless mods? I don't recall doing anything against people's wishes there. The sysctl mods were backed out relatively quickly... or did you bother to note that? Do you think I just commit things and then sit on them like a stone statue? If you look, carefully, you will find that I'm usually the first to admit when I've made a mistake and I fix things very quickly. As far as I know, there is nothing currently committed that anyone has a problem with except, perhaps /etc/rc.conf.local ... but I stood by that and it seems to have grown on people considering the recent discussions to expand the stacked configuration mechanisms. -- Since you seem to see it fit to accuse me of something in public, back it up on this forum. I have a complete archive, we can swap examples. I'll be plain: I'm a nice guy, and if you treat me fairly I'll treat you fairly. But I don't let people talk shit about me or shit to me if I think I'm in the right. I don't like vague accusations, either. If someone accuses me of something on a public forum, I answer on that forum, plain and simple. -Matt Matthew Dillon dil...@backplane.com :-- :Poul-Henning Kamp FreeBSD coreteam member :p...@freebsd.org Real hackers run -current on their laptop. :FreeBSD -- It will take a long time before progress goes too far! : To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: removing f2c from base distribution
If it is decided that Fortran support will disappear from the base system and nobody else wants to maintain g77, I will gladly do it. However, I will only maintain a version that I am using so that means I will maintain a port once gcc 2.8 is officially brought in as the stock compiler. Lets just crush the g77 port and tell people to install EGCS. I build g77 as part of that port. I welcome patches and feedback on the usablability of g77 w/in EGCS. -- -- 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: -Wall -Wcast-qual and SYSINIT
On Thu, 28 Jan 1999, Matthew Dillon wrote: Most of the functions do not expect a const argument, though that may simply be because they didn't bother to use const when they could have. However, I know at least the MALLOC initialization objects *can't* use const objects because the malloc initialization routine modifies the data object. OK I understand now.. theoretically I guess you should have two types of SYSINIT, however you are already not able to check the TYPE of the argument due to it being passed through the void form, so losing the 'const'-ness is not that much of a loss. The pragmetic answer may just be to 'cast' in the macro. I'm sure that a non-trivial number of the sysinits also modify their data objects. So we need to handle both cases. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: removing f2c from base distribution
Getting g77 from egcs is the best option right now. However, it seems to me that this adds a lot of bloat (duplication of C, C++, etc.) to the system for someone wanting to use FreeBSD as a scientific workstation platform. Then update the g77 port to fetch egcs-core-XYZ.tar.gz and egcs-g77-XYZ.tar.gz and build it that way. You will have no C, C++ or objC support in the result. -- -- 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: btokup() macro in sys/malloc.h
Matt, Please leave your keyboard now. Get some sleep, some rest and a couple of days off. You need it, we need it. Poul-Henning -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: -Wall -Wcast-qual and SYSINIT
On Wed, 27 Jan 1999, Matthew Dillon wrote:
Right now we have a problem with struct sysinit.
The problem is that some SYSINIT functions supply a function taking
a const void * and a const pointer for data, and other SYSINIT
functions supply a function taking a void * and a non-const pointer
for data.
What this means, effectively, is that we want one of two SYSINIT
structures where both the function argument and udata are of the
same type. Something like the union shown below. If the function
argument type does not match the data type we want the initialization
to generate a warning.
struct sysinit {
unsigned intsubsystem; /* subsystem identifier*/
unsigned intorder; /* init order within
subsystem*/
union {
struct {
void(*func) __P((void *));
void*udata; /* multiplexer/argument */
} n;
struct {
void(*func) __P((const void *));
const void *udata; /* multiplexer/argument */
} c;
} u;
si_elem_t type; /* sysinit_elem_type*/
};
Unfortunately, GCC isn't smart enough to match the function type
to the correct structure - it always stuffs it into the first structure.
Overloading a struct? Yuck :(
So the above cool hack will not work :-(.
Overloading is just a bad hack in concept.
I can't think of how to do this without actually having two different
sysinit structures - on that uses a non-const function and data element,
and one that uses a const function and data element. While having two
sysinit structures would work, it would be a little iffy keeping them
in sync with each other so the kernel init call code doesn't have to deal
with both types.
struct c_sysinit {
unsigned intsubsystem; /* subsystem identifier*/
unsigned intorder; /* init order within
subsystem*/
void(*func) __P((void *));
void*udata; /* multiplexer/argument */
si_elem_t type; /* sysinit_elem_type*/
};
struct n_sysinit {
unsigned intsubsystem; /* subsystem identifier*/
unsigned intorder; /* init order within
subsystem*/
void(*func) __P((const void *));
const void *udata; /* multiplexer/argument */
si_elem_t type; /* sysinit_elem_type*/
};
The SYSINIT problem accounts for about half the remaining compilation
warnings. I would like to find a good solution for it.
-Matt
Matthew Dillon
dil...@backplane.com
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Brian Feldman_ __ ___ ___ ___
gr...@unixhelp.org _ __ ___ | _ ) __| \
http://www.freebsd.org/ _ __ ___ | _ \__ \ |) |
FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: DEVFS, the time has come...
I agree.. and same thing goes for Ethernet drivers. I actually like the way Linux always has eth0, eth1, ... (which we could Yeagh... what is wrong with ed0, de0, fxp0 etc that needs changing? Is this just a matter of taste or is there more to it? I for one don't see any advantage in eth[0-9] style device naming. I can give you one example. We run a FreeBSD box here which receives all of the traffic (port mirroring) from some Ethernet switches. On the FreeBSD box, we run nnstat, tcpdump etc. for monitoring purposes. Recently I changed some of the DEC 21x4x based cards on this box to Intel cards. Thus the interface names changed from deN to fxpN. This meant we had to update a bunch of Perl and shell scripts. It would have been much nicer (no need to update) if the interfaces were simply named ethN. Personally, I'd also prefer to have IDE disks named daN, but that's another matter... Steinar Haug, Nethelp consulting, sth...@nethelp.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: NIS with HPUX 10.20
Why _not_ use -C? What is the point in replacing a file with the same file? install -C will replace the file if the new file is diffrent. Aaaah, thank you. I misread the manpage description of -C and didn't notice and the files are the same... Cleared up, head back on straight. :-) This is not so clear :-). -C always does a complete replacement of the file, as does -c, but the man page bogusly claims that the target file is overwritten. The complete replacement is necessary to snap any links (another undocumented feature). Someday -C should avoid touching the file if possible, so that it doesn't clobber the file's ctime and backups based on ctimes don't do unnecessary work. This is possible if none of the attributes except the file times would change, and fairly easy to implement if the file doesn't have any links. Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: -Wall -Wcast-qual and SYSINIT
: :Overloading a struct? Yuck :( : : : So the above cool hack will not work :-(. : :Overloading is just a bad hack in concept. Tell me something I don't know. If it were simple and straightforward, I'd have simply committed it. -Matt : Brian Feldman _ __ ___ ___ ___ : gr...@unixhelp.org _ __ ___ | _ ) __| \ Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DEVFS, the time has come...
On Thu, 28 Jan 1999, Harlan Stenn wrote: Also the eth[0..x] thing means you can replace your ethernet card with a new one of a different type without having to look through your config code for references to ed0 or whatever. Just to ask, what happens when the probe order changes and your multiple NICs start popping up on the wrong eth port? This may be *much* more difficult when one of several cards die (how do you know which one broke?) and then you replace it and discover the new probe order is different... Or will be be able to wire them down in the config file (which will at least address part of the problem)? If we did this, there would obviously have to be some kind of wiring system. The same problem exists in a much smaller way for machines with more that one of the same type of card. -- 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: DEVFS, the time has come...
On Thu, 28 Jan 1999, Leif Neland wrote: On Wed, 27 Jan 1999, Archie Cobbs wrote: Doug Rabson writes: And another thing. Why can't we use a non-driver-specific name for the disk? Most users simply don't care whether the driver was fd, wfd, wd or anything. They just want to get to their files without any fuss. I agree.. and same thing goes for Ethernet drivers. I actually like the way Linux always has eth0, eth1, ... (which we could do using netgraph, with some work). Just symlink eth0 to which card you like, just as /dev/mixer happens to be a symlink to /dev/mixer1 on my system. Unfortunately network devices aren't represented in /dev on BSD systems. -- 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: indent(1) and style(9) (was: btokup() macro in sys/malloc.h)
I see no evidence of this. vinum sources don't seem to have a single line in KNF, except accidentally. They have an indentation of 4 instead of 8, lots of per-statement comments, lots of lines longer than 80 characters, lots of block comments without `/*' and `*/' on a line by themself, ... not speaking about vinum, but to me, the indentation of 8 char and line length of 80 chars are almost mutually exclusive. See e.g. tcp_input.c ip_input.c and many network device drivers as an example -- basically all places where, for efficiency reasons, the code tries to expand in-line various block, the depth of indentation pushes everything to the right end leaving only 20-30 useful chars per line. cheers luigi ---+- Luigi RIZZO . EMAIL: lu...@iet.unipi.it. Dip. di Ing. dell'Informazione HTTP://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) ---+- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: btokup() macro in sys/malloc.h
Please do go ahead and update it.. the experts agree! I haven't seen any experts involved in this discussion yet. It's probably after bedtime down there in oz. It's been discussed before and agreed upon. There was only agreement long ago when the BSD4.4 /usr/src/admin/style was converted to a man page. Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: -Wall -Wcast-qual and SYSINIT
:On Thu, 28 Jan 1999, Matthew Dillon wrote: : :OK I understand now.. :theoretically I guess you should have two types of SYSINIT, :however you are already not able to check the TYPE of the argument due to :it being passed through the void form, so losing the 'const'-ness is not :that much of a loss. The pragmetic answer may just be to 'cast' in the :macro. I'd kinda like to keep the const-ness because I can see device drivers putting static structures in const ( i.e. read-only TEXT ) space and would like to have the safety factor of knowing that they aren't actually modified - not just not modified by the initialization routine, but also not modified later on in the device driver code. But I also want to eventually quiet the warning -- I agree that for SYSINIT's, loosing const is not a huge issue. Quieting the warning without fixing the problem with -Wcast-qual enabled is not pretty, though. I think -Wcast-qual is pretty important if we intend to fix the volatile conversion mess. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Celeron 333 kernel panic
Having just upgraded my motherboard/CPU to a BX chip set and Celeron 333 I attempted to boot into my 3.0-STABLE system. However, as soon as the kernel starts to boot I get panic: cpu class not configured and the machine reboots (and so on...) Is this cpu supported? Thanks, Mike -- Mike Zanker | Email: a.m.zan...@open.ac.uk Network and Computer Services Group | Tel : +44 1908 652726 The Open University | Fax : +44 1908 652193 Milton Keynes, UK | PGP public key available To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: btokup() macro in sys/malloc.h
:In cases, -Wall is bogus anyway. Here's one: :foo.c:89: warning: char format, void arg (arg 2) :void *region; :printf(mem open failed: %s\n, region); : :According to standards, a void pointer may be freely used instead of any :other type of pointer, both as an lvalue and to assign to the other pointer. :Printf(), hence, wouldn't see a difference (of course). Gcc should not :complain about various void pointer things like this. I think that's an appropriate warning... if you want to treat 'region' as a char *, you have to cast it to one. The standards do not cover GCC's automatic var-args checking for printf() and related routines anyway. I consider them 'weird' cases myself... not really standard, but helpful. -Matt Matthew Dillon dil...@backplane.com : Brian Feldman _ __ ___ ___ ___ : gr...@unixhelp.org _ __ ___ | _ ) __| \ :http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | : FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: btokup() macro in sys/malloc.h
On Thu, 28 Jan 1999, Poul-Henning Kamp wrote: In message 199901280222.vaa14...@khavrinen.lcs.mit.edu, Garrett Wollman writes: On Wed, 27 Jan 1999 18:00:54 -0800 (PST), Archie Cobbs arc...@whistle.com said: Please do go ahead and update it.. the experts agree! I haven't seen any experts involved in this discussion yet. It's probably after bedtime down there in oz. It's been discussed before and agreed upon. Actually it was discussed before and no agreement was reached.. The people with the biggest mouths yelled longest and loudest as usual and the sensible people said. It's like talking to 6 year olds, and gave up. There are times when extra braced and parens stop bugs from being introduced, due to the form of the code. There is no mention in style(9) of readability being a criteria for braces, which is ludicrus. julian To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: bug in nfs_access()
On Wed, 27 Jan 1999, Matthew Dillon wrote: bug in nfs_access(). nfs/nfs_vnops.c, line 414 or so. Fixed! This is a nasty one. I'm surprised it hasn't caused grief before I can't see the problem in this code. What was the bug? -- 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: bug in nfs_access()
: :On Wed, 27 Jan 1999, Matthew Dillon wrote: : : bug in nfs_access(). nfs/nfs_vnops.c, line 414 or so. : : Fixed! : : This is a nasty one. I'm surprised it hasn't caused grief before : :I can't see the problem in this code. What was the bug? --- nfs_vnops.c 1999/01/27 22:45:13 1.118 +++ nfs_vnops.c 1999/01/27 22:45:49 1.119 @@ -34,7 +34,7 @@ * SUCH DAMAGE. * * @(#)nfs_vnops.c 8.16 (Berkeley) 5/27/95 - * $Id: nfs_vnops.c,v 1.118 1999/01/27 22:45:13 dillon Exp $ + * $Id: nfs_vnops.c,v 1.119 1999/01/27 22:45:49 dillon Exp $ */ @@ -411,7 +411,7 @@ aiov.iov_len = auio.uio_resid = NFS_DIRBLKSIZ; error = nfs_readdirrpc(vp, auio, ap-a_cred); free(bp, M_TEMP); - } else if (vp-v_type = VLNK) + } else if (vp-v_type == VLNK) error = nfs_readlinkrpc(vp, auio, ap-a_cred); else error = EACCES; I believe the assignment to VLNK is incorrect and that it is supposed to be a comparison against VLNK instead. -Matt Matthew Dillon dil...@backplane.com :-- :Doug RabsonMail: 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 : To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
pcm0: thumbs up,down,up
pcm is again working correctly with the Yamaha YMF715 based sound system of my laptop. It had been working fine up till shortly before secure/libcrypt broke on -current. Then I had an array of strange problems. After testing and logging the various failures with cat, mpg123, xanim, rvplayer, and mtv threaded and unthreaded, I rebuilt the kernel with voxware and found that everything worked. I then rebuilt the kernel with pcm again and found that everything worked too. Well not exactly everything works. They each then and continue today to exhibit their unique little toubles. (volume doesn't work right under pcm (I have a patch), some versions of mtv audio don't work quite right via voxware, ...) -- Brian Litzinger br...@litzinger.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: indent(1) and style(9) (was: btokup() macro in sys/malloc.h)
not speaking about vinum, but to me, the indentation of 8 char and line length of 80 chars are almost mutually exclusive. See e.g. tcp_input.c ip_input.c and many network device drivers as an example -- basically all places where, for efficiency reasons, the code tries to expand in-line various block, the depth of indentation pushes everything to the right end leaving only 20-30 useful chars per line. See the Linux style guide (linux/Documentation/CodingStyle) for strong opinions about this: if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program. I almost agree. Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: bug in nfs_access()
On Wed, 27 Jan 1999, Matthew Dillon wrote: bug in nfs_access(). nfs/nfs_vnops.c, line 414 or so. Fixed! This is a nasty one. I'm surprised it hasn't caused grief before Never mind, I just read the commit message and managed to actually see the mistake. I hate those ones... -- 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: indent(1) and style(9) (was: btokup() macro in sys/malloc.h)
an example -- basically all places where, for efficiency reasons, the code tries to expand in-line various block, the depth of indentation pushes everything to the right end leaving only 20-30 useful chars per line. See the Linux style guide (linux/Documentation/CodingStyle) for strong opinions about this: if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program. I almost agree. in userland, probably me too. In the kernel, i am not so sure. luigi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: bug in nfs_access()
On Thu, 28 Jan 1999, Matthew Dillon wrote: : :On Wed, 27 Jan 1999, Matthew Dillon wrote: : : bug in nfs_access(). nfs/nfs_vnops.c, line 414 or so. : : Fixed! : : This is a nasty one. I'm surprised it hasn't caused grief before : :I can't see the problem in this code. What was the bug? --- nfs_vnops.c 1999/01/27 22:45:13 1.118 +++ nfs_vnops.c 1999/01/27 22:45:49 1.119 @@ -34,7 +34,7 @@ * SUCH DAMAGE. * * @(#)nfs_vnops.c 8.16 (Berkeley) 5/27/95 - * $Id: nfs_vnops.c,v 1.118 1999/01/27 22:45:13 dillon Exp $ + * $Id: nfs_vnops.c,v 1.119 1999/01/27 22:45:49 dillon Exp $ */ @@ -411,7 +411,7 @@ aiov.iov_len = auio.uio_resid = NFS_DIRBLKSIZ; error = nfs_readdirrpc(vp, auio, ap-a_cred); free(bp, M_TEMP); - } else if (vp-v_type = VLNK) + } else if (vp-v_type == VLNK) error = nfs_readlinkrpc(vp, auio, ap-a_cred); else error = EACCES; I believe the assignment to VLNK is incorrect and that it is supposed to be a comparison against VLNK instead. You are absolutely correct (I must still be half asleep). I guess that attempts to read from other filetypes didn't reach here or generated calls to the server which returned errors. -- 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
Nesting levels (was: indent(1) and style(9) (was: btokup() macro in sys/malloc.h))
On Thursday, 28 January 1999 at 20:39:03 +1100, Bruce Evans wrote: not speaking about vinum, but to me, the indentation of 8 char and line length of 80 chars are almost mutually exclusive. See e.g. tcp_input.c ip_input.c and many network device drivers as an example -- basically all places where, for efficiency reasons, the code tries to expand in-line various block, the depth of indentation pushes everything to the right end leaving only 20-30 useful chars per line. See the Linux style guide Wave a red rag at a bull? (linux/Documentation/CodingStyle) for strong opinions about this: if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program. I think this is the bottom line. If you're using 8 character indents, then yes, you're screwed. If you're using Microsoft and trying to write clever shell scripts, you're screwed too. Your tools limit what you can do. I believe that, in the matter of indentation, style(9) limits legibility to a point where you really are screwed if you have multiple indentation. But it's not because the code's bad. 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: Celeron 333 kernel panic
Mike Zanker wrote: Having just upgraded my motherboard/CPU to a BX chip set and Celeron 333 I attempted to boot into my 3.0-STABLE system. However, as soon as the kernel starts to boot I get panic: cpu class not configured and the machine reboots (and so on...) Is this cpu supported? AFAIK it is support - are you sure you had cpu I686_CPU In your kernel config? -Kp To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Celeron 333 kernel panic
On Thu, 28 Jan 1999, Mike Zanker wrote: Having just upgraded my motherboard/CPU to a BX chip set and Celeron 333 I attempted to boot into my 3.0-STABLE system. However, as soon as the kernel starts to boot I get panic: cpu class not configured and the machine reboots (and so on...) Is this cpu supported? Hi Did you Come from a Non Pentium II motherboard? have you tryed Recompileing your kernel for the 686 Class CPU's? if not then that is more likely to be the problem -- Phillip W. Hardyphil...@sis.bytes.gen.nz Secure Infomation Servics Software/Hardware Debugger FreeBSD the Choice of a GNU Generation - www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: btokup() macro in sys/malloc.h
In cases, -Wall is bogus anyway. Here's one: foo.c:89: warning: char format, void arg (arg 2) void *region; printf(mem open failed: %s\n, region); Yes, it should say warning: char * format, void * arg (arg 2). According to standards, a void pointer may be freely used instead of any other type of pointer, both as an lvalue and to assign to the other pointer. There are no lvalues or assigns to another pointer here. The code does what you want (if `region' is a char * represented as a void *) only because void * has the same representation as char *. Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: PPP (userland) troubles ?
On Wed, 27 Jan 1999, Brian Somers wrote: To find out if this is the problem, can you try connecting interactively. You should see the same delay. You can then try again, but during the delay, pressing return a few times at the prompt should wake ppp up. Is this happening ? Well, I tried and didn't find any relationship between pressing return and triggering the wakeup. This is someway hard to find, since ppp wakes up automagically a few couple of seconds after the connection has been established. However: I noticed a real big commit to ppp last night, so I decided to wipe out /usr/src/usr.sbin/ppp + /usr/src/sys completely, recvsup'd, recompiled kernel, ppp and tested again - problems are gone. So there are now 2 possibilities for this problem: a) I was out of sync :( b) Someone fixed ppp -- # /AS/ http://privat.schlund.de/entropy/ # # # # XX has detected, that your mouse cursor has changed position. Please # # restart XX, so it can be updated.-- From The Gimp manual # To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Celeron 333 kernel panic
At 09:53 28/01/99 , Karl Pielorz wrote: AFAIK it is support - are you sure you had cpu I686_CPU In your kernel config? Thanks, this is the problem - I've only got I586_CPU in my config. I *knew* I should have kept a GENERIC kernel around! Thanks to all who answered, Mike -- Mike Zanker | Email: a.m.zan...@open.ac.uk Network and Computer Services Group | Tel : +44 1908 652726 The Open University | Fax : +44 1908 652193 Milton Keynes, UK | PGP public key available To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: btokup() macro in sys/malloc.h
A warning is just that. It's not an error, so don't treat it like one. I use different productions to enable different warnings on code with different histories. For one thing, new revs of the compiler will otherwise cause trouble when the warning behavior changes. I also use -Werror. Eliminating warnings is almost pointless without this. And yeah, I have a NO_WERROR flag for when I'm in a rush. I know -Werror is the eventual goal. So I disagree with Nate about ignoring warnings you've enabled - it is too easy to ignore a new problem. I agree with him that gratuitous casts and similar fixes during damn-the-torpedos mass conversions of large bodies of code are bad in that they can effectively hide latent problems more deeply than they were hidden before such a conversion. So IMHO: Eliminating warnings is good; Any mechanistic change to eliminate warnings that can mask problems can not be used. Peter -- Peter Dufault (dufa...@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: removing f2c from base distribution
Chuck Robey wrote: I'm not sure if this argument is worth pushing anymore, because FreeBSD's stability and usefulness has become much more well known, but it did contribute at some point, and I think that is the idea that Daniel was trying to convey. Right? Me? No... Maybe Garret... :-) -- Daniel C. Sobral(8-DCS) d...@newsguy.com If you sell your soul to the Devil and all you get is an MCSE from it, you haven't gotten market rate. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: -Wall -Wcast-qual and SYSINIT
From my uderstanding, SYSINIT should always point to a function with a CONST argument because the argument is fixed as a constant at link/compile time. what functions don't expect a const? and why not? Probably most. or am I mising something? Only the initial value of the arg is determined at link/compile time. The arg can point to non-const storage, and it is not unreasonable to put the initial value in non-const storage so that it can be frobbed. Linker sets sometimes get frobbed. I once made execsw_set const and had to change it back after it started causing warnings. Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Naming files in sys/kern
On Wed, 27 Jan 1999 18:30:15 -0500 (EST), Robert Watson rob...@cyrus.watson.org said: It's not clear to me, when thinking of introducing a new file (say, for auditing support :), what I should name it. Would it be kern_audit.c or sys_audit.c? Depends on what it is auditing. If it only auditing the basic I/O operations, then it would go in sys_*.c. If it's a more general kernel facility, then it goes in kern_*.c. Or, if it is POSIX.1e, would it go into a /usr/src/sys/posix1e directory as the posix4 realtime stuff did (assuming that support for additional features from that posix draft were going to be forthcoming)? Giving the unhelpful tendency of Project 1003 to renumber its standards after-the-fact (or fold them into the main 1003.1 document), I would suggest against using committee identifiers like this. This is posix4 due to my stupidity - I bought the O'Reilly posix.4 book and changed the name to that even though I used to know better. I started with this in its own directory since it is supposed to be able to be enabled/disabled en masse via feature test macros, and because I wanted to keep all the posixy stuff in one place with calls out into the regular BSD kernel. Since the name is wrong, I think right thing to do now is make this directory something that means posix_subsystem and put similar chunks that follow similar rules there. That keeps the code associated with twisty standardized feature test macros in one place. Peter -- Peter Dufault (dufa...@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: indent(1) and style(9) (was: btokup() macro in sys/malloc.h)
They have an indentation of 4 instead of 8, [.] 8 spaces is almost always *way* too much if a maximum of 80 columns is expected. IMHO, the requirement should be to either use TABs and only TABs or else two or more spaces. Either way, perhaps it's time someone fixed indent(1) so that it applies style(9)... Bruce -- Brian br...@awfulhak.org br...@freebsd.org br...@openbsd.org http://www.Awfulhak.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: indent(1) and style(9) (was: btokup() macro in sys/malloc.h)
See the Linux style guide (linux/Documentation/CodingStyle) for Looks like an oxymoron to me. Bruce -- Brian br...@awfulhak.org br...@freebsd.org br...@openbsd.org http://www.Awfulhak.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: indent(1) and style(9) (was: btokup() macro in sys/malloc.h)
an example -- basically all places where, for efficiency reasons, the code tries to expand in-line various block, the depth of indentation pushes everything to the right end leaving only 20-30 useful chars per line. See the Linux style guide (linux/Documentation/CodingStyle) for strong opinions about this: if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program. I almost agree. in userland, probably me too. In the kernel, i am not so sure. What's the difference ? I've heard people suggesting the opposite in the past - ``low level code is long and thin, high level code is wider''. But the kernel isn't the only place you find low level code. luigi -- Brian br...@awfulhak.org br...@freebsd.org br...@openbsd.org http://www.Awfulhak.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: PPP (userland) troubles ?
So there are now 2 possibilities for this problem: a) I was out of sync :( b) Someone fixed ppp Last nights commit was for RADIUS support in ppp. There was another latency problem that I fixed about a week ago - maybe that was it :-) -- # /AS/ http://privat.schlund.de/entropy/ # # # # XX has detected, that your mouse cursor has changed position. Please # # restart XX, so it can be updated.-- From The Gimp manual # -- Brian br...@awfulhak.org br...@freebsd.org br...@openbsd.org http://www.Awfulhak.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Netscape | Mozilla
* From: Luke l...@aus.org * linux_lib port. [why does it install into / anyways] You can put it anywhere and symlink to it, like sysinstall does now, but it has to be called /compat (or some other well-known place) because of the implementation. The string /compat/linux has to be hardcoded in the linux emulator binary. (If we move it to /usr/local/compat, people who use LOCALBASE other than /usr/local will be screwed, etc.) I know, I tried to change it before until I realized that it's not that easy. Satoshi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: btokup() macro in sys/malloc.h
Peter Jeremy wrote: I'll support that. The example given in style(9): a = b-c[0] + ~d == (e || f) || g h ? i : j 1; should rate as an entry in the Obfuscated C competition rather than an example of maintainable code. As a matter of fact, what's the reasoning behind this particular style(9) recommendation? -- Daniel C. Sobral(8-DCS) d...@newsguy.com If you sell your soul to the Devil and all you get is an MCSE from it, you haven't gotten market rate. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: btokup() macro in sys/malloc.h
Bruce Evans wrote: It would be nice if style(9) documented the options to give indent(1) to match the `approved' layout convections. (This would reduce the effort involved in importing large chunks of code). This is impossible, since indent(1) is buggy and out of date with both KNF and C. Well... add it to the projects in the handbook... :-) (seriously...) -- Daniel C. Sobral(8-DCS) d...@newsguy.com If you sell your soul to the Devil and all you get is an MCSE from it, you haven't gotten market rate. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
LDT changes to support SysVR4 emulator
Ok, people, heads up -- I'm about to commit a patch to /sys/i386 which changes the way FreeBSD uses the x86 LDT. Specifically, I'm moving LUDATA_SEL from LDT entry 4 to 5 (Why 5? Why not?) and re-using entry 4 as a call gate for SysV system calls made by library stubs from Solaris 2.6 and higher. I've been running with these mods for about a month now with no problems at all (there are no userland implications AFAICT). Nevertheless, I'm going to leave this in for a couple of days before committing the rest of the emulator to give interested parties a chance to bitch at me :-) Cheers, - mark I tried an internal modem,new...@atdot.dotat.org but it hurt when I walked. Mark Newton - Voice: +61-4-1958-3414 - Fax: +61-8-83034403 - To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: btokup() macro in sys/malloc.h
* From: John Polstra j...@polstra.com * On 28-Jan-99 Bruce Evans wrote: Hey John, are you sure your mailer is Y2K compliant? Satoshi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: btokup().. patch to STYLE(9) (fwd)
Some people when confronted by people wanting to have extra braces
say change style(9).
Well, here is my change..
I think theere is enough support for this that this should be discussed
seriously, and It's not like in the good old days, or
I'm not used to extra parenthesis are not going to be considerred as
good reasons for not committing this.. Anyone can have reasons of that
level.
The aim to allow more braces and parens when needed for clarity.
Clarity is decided by the person who get's confused because they ar enot
there.
Index: style.9
===
RCS file: /cvs/freebsd/src/share/man/man9/style.9,v
retrieving revision 1.22
diff -u -r1.22 style.9
--- style.9 1997/12/07 20:25:45 1.22
+++ style.9 1999/01/28 09:07:46
@@ -256,13 +256,23 @@
.Ed
.Pp
Space after keywords (if, while, for, return, switch). No braces are
-used for control statements with zero or only a single statement.
+used for control statements with zero or only a single statement unless that
+statement is more than a single line in which case they are permitted.
Forever loops are done with for's, not while's.
.Bd -literal -offset 0i
for (p = buf; *p != '\e0'; ++p)
; /* nothing */
for (;;)
stmt;
+ for (;;) {
+ z = a + really + long + statement + that + needs +
+ two lines + gets + indented + four + spaces +
+ on + the + second + and + subsequent + lines;
+ }
+ for (;;) {
+ if (cond)
+ stmt;
+ }
if (val != NULL)
val = realloc(val, newsize);
.Ed
@@ -290,7 +300,7 @@
and do not use spaces in front of tabs.
.Pp
Closing and opening braces go on the same line as the else.
-Don't add braces that aren't necessary.
+Braces that aren't necessary may be left out.
.Bd -literal -offset 0i
if (test)
stmt;
@@ -318,7 +328,8 @@
.Pp
Unary operators don't require spaces, binary operators do. Don't
use parentheses unless they're required for precedence, or the
-statement is really confusing without them.
+statement is confusing without them. Remember that other people may
+confuse easier then you. Do YOU understand the following?
.Bd -literal -offset 0i
a = b-c[0] + ~d == (e || f) || g h ? i : j 1;
k = !(l FLAGS);
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: PPP (userland) troubles ?
Brian Somers wrote: So there are now 2 possibilities for this problem: a) I was out of sync :( b) Someone fixed ppp Last nights commit was for RADIUS support in ppp. There was another latency problem that I fixed about a week ago - maybe that was it :-) Yuck! (jumping in the air and clapping with my feet!!) -- Andre To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Celeron 333 kernel panic
At 10:13 28/01/99 , Mike Zanker wrote: Thanks, this is the problem - I've only got I586_CPU in my config. I *knew* I should have kept a GENERIC kernel around! OK, I've been very, very silly and not kept a GENERIC kernel around and cannot boot with my existing kernel. Is there some way of booting from floppy (e.g. boot.flp from 3.0-RELEASE or 3.0-SNAP) and copying a GENERIC kernel to my existing root partition. I should be very grateful if someone could point me in the direction of any documentation. Thanks in advance, Mike -- Mike Zanker | Email: a.m.zan...@open.ac.uk Network and Computer Services Group | Tel : +44 1908 652726 The Open University | Fax : +44 1908 652193 Milton Keynes, UK | PGP public key available To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Celeron 333 kernel panic
On Thu, 28 Jan 1999, Mike Zanker wrote: OK, I've been very, very silly and not kept a GENERIC kernel around and cannot boot with my existing kernel. Is there some way of booting from floppy (e.g. boot.flp from 3.0-RELEASE or 3.0-SNAP) and copying a GENERIC kernel to my existing root partition. I should be very grateful if someone could point me in the direction of any documentation. Hi Mike Tryed usering Fixit floppy... useing the fixit floppy you can then mount your root filesystem.. and start mounting other filesystems like /var /usr etc. and then goto /usr/src/sys/i386/conf edit your hostnamefile.. Add 686 support config hostname ; cd ../../compile/hostname make clean ; make depend ; make ; make install Reboot (x fingers) and hopefully you will be back with us) Phill To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: btokup() macro in sys/malloc.h
John Polstra j...@polstra.com wrote: On 28-Jan-99 John Birrell wrote: John Polstra wrote: Hear ye, hear ye! Be it here noted and archived for all eternity that on January 27, 1999 Pacific Time, John Polstra was, for one fleeting moment, purer than Bruce! :-) OK, so now we have to shoot you too. Oh well, so be it Are there any others who would like to join these purists? Come on, we have bullets for you all... Bah! You might be able to hit Bruce over there in oz. But to hit me, you'd need an ICBM. Give me purity or give me death! Bwahahahahah! That's ok -- We'll give you death. We have your ICBM address: John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA Come to think of it, that might solve a few other problems too. Linus Torvalds may want world domination, but I think our way has the potential to be quicker... - mark :-) I tried an internal modem,new...@atdot.dotat.org but it hurt when I walked. Mark Newton - Voice: +61-4-1958-3414 - Fax: +61-8-83034403 - To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
boot.flp in 1/27/98 -STABLE...
I've just finished building my n'th release of -STABLE, and that dang boot floppy is still too big. I know I came in on the trailing edge of the discussion to change the whole boot thing, but after poking through a few ideas, and testing them out, I came up with a few that might make for a reasonable transition... So people that wanted to use -STABLE could boot from a floppy or CD while the 'real solution' was worked out, without having to install 3.0-RELEASE, then go through the upgrade process My first thought was to use a 2.88MB floppy image. I've heard mixed results on LS-120 drives, but I know that CDs can use them, solving at least half the problem. My second thought was to possibly use the Stressed floppy formats. The fd1720 looks more than big enough to hold the whole thing, as it appears that the only thing missing from boot.flp is the boot directory, coming in at 200-and-something K (lets just say 300K, its been a few hours since I looked at it). If this stressed format is actually real, it should work. I haven't checked to see if a CD boot program will recognize this or not, so that may be a gotcha In any event, a 2 floppy boot works, but its a pain to tote two floppies around when you're used to just popping the CD in Anyhow, just making some band aid suggestions to try to increase the exposure of -STABLE so we can use it a lot more, and find more bugs -Brian To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: NIS with HPUX 10.20
On Thu, Jan 28, 1999 at 08:06:58PM +1100, Bruce Evans wrote: Someday -C should avoid touching the file if possible, so that it doesn't clobber the file's ctime and backups based on ctimes don't do unnecessary work. This is possible if none of the attributes except the file times would change, and fairly easy to implement if the file doesn't have any links. Hm... Two conflicting goals: Avoid backing up too much. Identify deprecated files. The solutions I can think of (so far) are quite ugly... -- Zach Heilig z...@uffdaonline.net / Zach Heilig z...@gaffaneys.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Naming files in sys/kern
On Wed, 27 Jan 1999, Garrett Wollman wrote: On Wed, 27 Jan 1999 18:30:15 -0500 (EST), Robert Watson rob...@cyrus.watson.org said: It's not clear to me, when thinking of introducing a new file (say, for auditing support :), what I should name it. Would it be kern_audit.c or sys_audit.c? Depends on what it is auditing. If it only auditing the basic I/O operations, then it would go in sys_*.c. If it's a more general kernel facility, then it goes in kern_*.c. The spec has audit records describing all POSIX.1 calls (fork, etc). They also allow for additional audit records that are application or system defined (such as a login audit record, or a socket audit record). As such, I'll assume kern_audit.c. I do notice, however, that subr_log.c is fairly similar to what I'm doing (at least in that it has a /dev/log for a userland process, and is referenced hither and thither). Or, if it is POSIX.1e, would it go into a /usr/src/sys/posix1e directory as the posix4 realtime stuff did (assuming that support for additional features from that posix draft were going to be forthcoming)? Giving the unhelpful tendency of Project 1003 to renumber its standards after-the-fact (or fold them into the main 1003.1 document), I would suggest against using committee identifiers like this. This is further confused by the fact that this draft (as I understand it) will not be made a standard. However, Solaris and Linux both seem to have ACL implementations, and Linux the Capabilities implementation. (Linux does not have file system support for these, however) The auditing code will be useful for a project I'm working on, so I figured I'd do that first. If it's controlled by a compile-time option, it should probably be called POSIX_AUDITING rather than POSIX_1e or something of that nature, since your statement implies that there is a useful granularity of features. The components of 1e (and 2c, the userland utilities associated with 1e): ACLs Capabilities Auditing MAC Information Labels The order of interest for me is Auditing, Capabilities, ACLs, and then the remaining two. Auditing has immediate benefit to a project of mine; it requires fairly comprehensive userland library support, so it may take a few weeks. To do ACLs, I need some place to store ACLs, such as additional file forks or a centralized file like quotas use--I'm not sure I want to deal with them yet, although they would be nice to have. I have not reviewed Capabilities in detail--they don't seem horribly useful to me in terms of the standard capabilities they define--however, adding some of our own that are more tailored to BSD would be useful. MAC and Information Labels are clearly useful--that is, if someone wants to try and make FreeBSD Bx rated :). I'll do these if I have time, probably this summer. For now, I'll add options: POSIX_AUD POSIX_ACL POSIX_CAP POSIX_MAC POSIX_INF Which are consistent with the run-time defines associated with the features (the run-time defines have _'s in front). Robert N Watson rob...@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C Carnegie Mellon Universityhttp://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ SafePort Network Services http://www.safeport.com/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: NIS with HPUX 10.20
No. installworld more or less assumes single user. This is really what I'm getting at. :-) If installworld assumes single-user mode, why do we install -C ld-elf.so.1 ? The first time I asked this question, I didn't mention single-user mode and your answer was that it's to protect live systems. What's so live about a single-user system that we can't assume nothing else needs ld-elf.so.1 while we're smacking it? For ld.so, it seems to have been just to make things work in multi-user mode: RCS file: /home/ncvs/src/libexec/rtld-aout/Makefile,v Working file: Makefile head: 1.27 ... revision 1.16 date: 1996/01/11 03:45:55; author: jdp; state: Exp; lines: +13 -2 Install ld.so in a way that is safe even on a running system. Perhaps it is useful even in single user mode for `make -j2 world'. Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Celeron 333 kernel panic
On Thu, 28 Jan 1999, Mike Zanker wrote: Having just upgraded my motherboard/CPU to a BX chip set and Celeron 333 I attempted to boot into my 3.0-STABLE system. However, as soon as the kernel starts to boot I get panic: cpu class not configured and the machine reboots (and so on...) Is this cpu supported? As far as I know, yes. Check your kernel config and include cpu I686_CPU (valid for Pentium Pro, P2 and probably celerons). You could comment out the other cpu options, but this isn't 100% necessary. They don't do any harm, but they *might* have an impact on performance and probably bloat the kernel a bit. (the GENERIC kernel always includes all cpu types, that's why it is called GENERIC, i think :) -- # /AS/ http://privat.schlund.de/entropy/ # # # # XX has detected, that your mouse cursor has changed position. Please # # restart XX, so it can be updated.-- From The Gimp manual # To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Reading a text file with BTX
Is there a way to view the contents of a text file (specifically, /boot/loader.rc) with BTX? Now that there are all these nifty new modules, my kernel is a lot smaller and my /boot/loader.rc is a lot longer. The way I have my /boot/loader.rc setup is such that it unloads everythin automatically loaded if I drop to the BTX prompt instead of autobooting. This is fairly convenient except when I want to boot an alternate kernel but still load all the same modules that I use in my default kernel. If there isn't such a feature, it would be really nice if there were a 'cat' command or something along those lines so that I could read the contents of /boot/loader.rc and get everything properly reloaded by hand. Could it be added or could I just make my own somehow? Thanks a bunch. -Patrick Patrick L. Hartling | Research Assistant, ICEMT myst...@friley-184-92.res.iastate.edu | Carver Lab - 0095E Black Engineering http://www.public.iastate.edu/~oz/ | http://www.icemt.iastate.edu/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: btokup() macro in sys/malloc.h
On Thu, 28 Jan 1999 19:56:37 +0900, Daniel C. Sobral d...@newsguy.com said: Peter Jeremy wrote: I'll support that. The example given in style(9): a = b-c[0] + ~d == (e || f) || g h ? i : j 1; should rate as an entry in the Obfuscated C competition rather than an example of maintainable code. As a matter of fact, what's the reasoning behind this particular style(9) recommendation? I believe that it was an attempt on Berkeley's part to ``raise the bar'' for kernel coders -- `if you don't know the C operator precedence table by heart, you shouldn't be writing kernel code'. Obviously, it didn't work, or we wouldn't be here today. -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
Style (was Re: btokup()..)
| :I think that style(9) should be modified to include | :Parenthesis may be used to improve the readbility of complex | :expressions even if not strictly required. | :instead of the stupid phrase presently there. | :also: | :Braces around code blocks should be allowable even when not strictly | :needed, for the purpose of readbility. | : | :The aim is to produce readble maintainable code, not to save bytes in | :sourcecode! | | I agree completely. I've already gotten into the habit of added | braces when conditonal expressions exceed one line, even though there | may be only one statement. Otherwise the code is just too unreadable. Is there an ident style for (x)emacs to enforce/promote this style? *emacs never inserts code, so you couldn't get it to 'add' parentheses or braces to code. It doesn't even whine about them. The only thing that it does is move your white-space around. Nate To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Netscape | Mozilla
* From: Luke l...@aus.org
* linux_lib port. [why does it install into / anyways]
You can put it anywhere and symlink to it, like sysinstall does now,
but it has to be called /compat (or some other well-known place)
because of the implementation. The string /compat/linux has to be
hardcoded in the linux emulator binary. (If we move it to
/usr/local/compat, people who use LOCALBASE other than /usr/local
will be screwed, etc.)
I know, I tried to change it before until I realized that it's not
that easy.
Install it in $PREFIX/compat and then make a symlink from /compat to
${PREFIX}/compat. This only fails if you then install the SVR4 stuff
with a different ${PREFIX}, which will screw you anyway. 8)
--
\\ 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: LDT changes to support SysVR4 emulator
Mark Newton wrote: Ok, people, heads up -- I'm about to commit a patch to /sys/i386 which changes the way FreeBSD uses the x86 LDT. Specifically, I'm moving LUDATA_SEL from LDT entry 4 to 5 (Why 5? Why not?) and re-using entry 4 as a call gate for SysV system calls made by library stubs from Solaris 2.6 and higher. Have you tested how this might affect wine? -- Steve finger ka...@troutmask.apl.washington.edu http://troutmask.apl.washington.edu/~clesceri/kargl.html To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: mergemaster should be merged in to the main tree.
Jaye Mathisen wrote: This utility is too valuable for all the update not to at least have a mention of it. Thank you. :) The occasional compliment makes the hard work worthwhile. At the very least, references should be made to it in /usr/src/Makefile as part of the conversion process, and inthe /usr/src/UPDATING file. I wouldn't object to it being publicized more than it is.. I don't have a /usr/src/UPDATING file though, is that something new in 3.x? I would be willing to get permission from the author if people think it's a good idea. *Wave* I don't think putting it in the base is really feasible, since the chances of me getting commit privileges to do that are very small. :) Besides, I would much rather see the installation routine modified to include various things from the ports/packages tree rather than continuing to add (arguably) non-critical things to the base. There are a lot of people who install FreeBSD who don't upgrade very often, and to them something like mergemaster would be bloat. What I'd like to see is a section of sysinstall that asks what the user is going to do with freebsd, and suggests some packages to install. E.g., Are you planning to upgrade your system on a regular basis? Ok, here's some things you should install, like cvsup, mergemaster, etc. Doug -- *** Chief Operations Officer, DALnet IRC network *** Like desperadoes waiting for a train . . . To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: -Wall -Wcast-qual and SYSINIT
In article 199901280753.xaa98...@apollo.backplane.com, Matthew Dillon dil...@apollo.backplane.com wrote: Unfortunately, GCC isn't smart enough to match the function type to the correct structure - it always stuffs it into the first structure. Don't blame GCC. The C standard requires it to behave the way it does. Anyway, GCC actually does have an extension that addresses this problem. See Labeled Elements in Initializers in the info pages. Note, this extension should NOT be used, in my opinion. John -- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA Nobody ever went broke underestimating the taste of the American public. -- H. L. Mencken To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: -Wall -Wcast-qual and SYSINIT
:Anyway, GCC actually does have an extension that addresses this :problem. See Labeled Elements in Initializers in the info pages. :Note, this extension should NOT be used, in my opinion. : :John :-- : John Polstra j...@polstra.com : John D. Polstra Co., Inc.Seattle, Washington USA I'm going to clarify the situation by comitting a separation of SYSINIT to SYSINIT ( for void * stuff ) and C_SYSINIT ( for const void * stuff ). However, they will use the same structure and thus will not address the warning at all. This is simply a clarification of the problem. This is in sys/kernel.h, of course. The auxillary macros, such as in sys/vnode.h, simply use the 'correct' *SYSINIT macro. What we need is a solution for C_SYSINIT that allows the const void * callback and data case through without warning, but does not allow the void * callback and data case. Just as the current SYSINIT case allows the void * callback/data case without warning but complaints on const void * callback/data. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Change to SVIDEO on bt848 driver
Hi, I have finally corrected a long standing bug in the bt848 driver with regard to selecting the SVIDEO input for true SVIDEO camera and for the many normal cameras connected via the SVIDEO port (eg the bundled hauppauge camera). As a result some applications which select SVIDEO input sources and incorrcetly used METEOR_INPUT_DEV2 for the METEORSFORMAT ioctl will now see a monochrome picture. The fix is to change the code to pass METEOR_INPUT_DEV_SVIDEO as the parameter for the METEORSFORMAT ioctl. I know this fix is ok with vic but breaks fxtv 0.47 when used with true s-video sources. I have sent patches to Randall, but for now, you can download a new fxtv tarball from me. This is available upon request to prevent a mixup of official fxtv and 'rogers fxtv patch'. email to ro...@cs.strath.ac.uk please. Thanks Roger To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Argument by Authority
On Thu, 28 Jan 1999 05:48:31 +0200 (SAT), Robert Nordier rnord...@nordier.com said: | COMPATIBILITY | The rm utility differs from historical implementations in that | the -f option only masks attempts to remove non-existent | files instead of masking a large variety of errors. I went down to our reading room and examined 1003.2. It says quite clearly that `-f' has ONLY the following two effects: 1) Suppress warnings for non-existent files specified on the command line. 2) Suppress interaction when removing an unwritable file even when standard input is connected to a terminal. It specifically requires that diagnostics be generated for any errors resulting from unlink() or rmdir(). (The rationale dismisses the historic behavior by describing it as ``hardly doing a service to either shell programmers or interactive users''.) The synopsis given is: rm [-firR] file ... ...which indicates that at least one `file' argument is required. It also indicates that `-f' and `-i' are not mutually exclusive. Furthermore, 1003.2 prohibits our `-d' flag; `rm' is always required to call rmdir() when a directory is specifed on the command line. -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: DEVFS, the time has come...
From: Wilko Bulte wi...@yedi.iaf.nl Date: Wed, 27 Jan 1999 23:12:18 +0100 (CET) Yeagh... what is wrong with ed0, de0, fxp0 etc that needs changing? Is this just a matter of taste or is there more to it? I for one don't see any advantage in eth[0-9] style device naming. It's a matter of whether you want the name to reflect the implementation vs. the function. For someone involved in the details of the implementation, being (acutely!) aware of those details can be very important. For someone who merely wants to have a certain physical port on the machine connected to a particular network, that level of detail is not always appropriate. It depends on your focus. Cheers, david -- David Wolfskill UNIX System Administrator d...@whistle.comvoice: (650) 577-7158 pager: (650) 371-4621 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Hmmm.. more on the eis ahb bug
On Wed, 27 Jan 1999, Matthew Dillon wrote: Could an Adaptec SCSI guru take a look at this code ? There's probably some poor sob running EISA who's scratching his head right now :-) Hey! Actually, my EISA box with a 1742 has been having weird lockups. Not sure if that has anything to do with this bug. -- | Matthew N. Dodd | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS | | win...@jurai.net | This Space For Rent | ix86,sparc,m68k,pmax,vax | | http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage? | To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Nesting levels (was: indent(1) and style(9) (was: btokup() macro in sys/malloc.h))
On Thu, 28 Jan 1999, Greg Lehey wrote: On Thursday, 28 January 1999 at 20:39:03 +1100, Bruce Evans wrote: See e.g. tcp_input.c ip_input.c and many network device drivers as an example -- basically all places where, for efficiency reasons, the code tries to expand in-line various block, the depth of indentation pushes everything to the right end leaving only 20-30 useful chars per line. See the Linux style guide Wave a red rag at a bull? :) (linux/Documentation/CodingStyle) for strong opinions about this: if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program. I think this is the bottom line. If you're using 8 character indents, then yes, you're screwed. If you're using Microsoft and trying to write clever shell scripts, you're screwed too. Your tools limit what you can do. I believe that, in the matter of indentation, style(9) limits legibility to a point where you really are screwed if you have multiple indentation. But it's not because the code's bad. I really wish style(9) had some suggestions for configuring editors to make it easier to conform to the standards. Telling people add this to your exrc/gvimrc/emacsrc would help people trying to adopt the guidlines supplied in the manpage. Anyone want to commit thier editor's rc file to some place in /usr/share/examples? It'd be much appreciated. thanks, -Alfred To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Reading a text file with BTX
Patrick Hartling wrote: Is there a way to view the contents of a text file (specifically, /boot/loader.rc) with BTX? Now that there are all these nifty new modules, my kernel is a lot smaller and my /boot/loader.rc is a lot longer. The way I have my /boot/loader.rc setup is such that it unloads everythin automatically loaded if I drop to the BTX prompt instead of autobooting. This is fairly convenient except when I want to boot an alternate kernel but still load all the same modules that I use in my default kernel. If there isn't such a feature, it would be really nice if there were a 'cat' command or something along those lines so that I could read the contents of /boot/loader.rc and get everything properly reloaded by hand. Could it be added or could I just make my own somehow? Thanks a bunch. You might be refering to the loader prompt, not the btx prompt. If you type something as soon as the first | is shown, that's btx. If you wait a little, or enter /boot/loader, then you get loader. Specifically, if it has processed loader.rc, then you are inside loader, not btx. Loader has a command called autoboot, which runs by default with 10 seconds wait. This one shows a countdown of seconds. If you interrupt here, you are in loader. Now, I don't know about btx, but here is what is in for you with loader... Conditional loading is possible, though Mike committed it to RELENG_3 instead of -current, and has not corrected that yet. bin/9662, in case you want. You can put that code inside /boot/boot.4th, and it will be loaded before loader.rc, so you *could* use it inside loader.rc. Unfortunately, *that* still doesn't work. I have it almost working on my system. I think I'm down to the last bug (I think that because it works perfectly as long as no error happens inside the script). Showing contents of a file happens to be possible too, as soon as bin/9753 gets in. Jordan promised cat and more for us, but since he is too busy with his update targets, I decided to get more in. :-) -- Daniel C. Sobral(8-DCS) d...@newsguy.com If you sell your soul to the Devil and all you get is an MCSE from it, you haven't gotten market rate. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Reading a text file with BTX
Daniel C. Sobral d...@newsguy.com wrote: } Patrick Hartling wrote: } } Is there a way to view the contents of a text file (specifically, } /boot/loader.rc) with BTX? Now that there are all these nifty new modules, } my kernel is a lot smaller and my /boot/loader.rc is a lot longer. The way } I have my /boot/loader.rc setup is such that it unloads everythin } automatically loaded if I drop to the BTX prompt instead of autobooting. } This is fairly convenient except when I want to boot an alternate kernel but } still load all the same modules that I use in my default kernel. If there } isn't such a feature, it would be really nice if there were a 'cat' command } or something along those lines so that I could read the contents of } /boot/loader.rc and get everything properly reloaded by hand. Could it be } added or could I just make my own somehow? Thanks a bunch. } } You might be refering to the loader prompt, not the btx prompt. If } you type something as soon as the first | is shown, that's btx. If } you wait a little, or enter /boot/loader, then you get loader. } Specifically, if it has processed loader.rc, then you are inside } loader, not btx. Ah, I see. Sorry for using the wrong name, but you did figure out what I meant which is good. :) } Showing contents of a file happens to be possible too, as soon as } bin/9753 gets in. Jordan promised cat and more for us, but since he } is too busy with his update targets, I decided to get more in. :-) Cool beans, that's what I was curious about. Thanks for the info. -Patrick Patrick L. Hartling | Research Assistant, ICEMT myst...@friley-184-92.res.iastate.edu | Carver Lab - 0095E Black Engineering http://www.public.iastate.edu/~oz/ | http://www.icemt.iastate.edu/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DEVFS, the time has come...
As sth...@nethelp.no wrote... I agree.. and same thing goes for Ethernet drivers. I actually like the way Linux always has eth0, eth1, ... (which we could Yeagh... what is wrong with ed0, de0, fxp0 etc that needs changing? Is this just a matter of taste or is there more to it? I for one don't see any advantage in eth[0-9] style device naming. I can give you one example. We run a FreeBSD box here which receives all of the traffic (port mirroring) from some Ethernet switches. On the FreeBSD box, we run nnstat, tcpdump etc. for monitoring purposes. Recently I changed some of the DEC 21x4x based cards on this box to Intel cards. Thus the interface names changed from deN to fxpN. This meant we had to update a bunch of Perl and shell scripts. It would have been much nicer (no need to update) if the interfaces were simply named ethN. Hmmm. Well I happen to like the concept of being able to tell straight away what device I'm talking to. eth# style naming does not allow that. But I can understand that other people might feel otherwise. Wilko _ __ | / o / / _ Bulteemail: wi...@yedi.iaf.nl |/|/ / / /( (_) Arnhem, The Netherlands WWW : http://www.tcja.nl __ Powered by FreeBSD __ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DEVFS, the time has come...
As Daniel O'Connor wrote... On 27-Jan-99 Wilko Bulte wrote: I agree.. and same thing goes for Ethernet drivers. I actually like the way Linux always has eth0, eth1, ... (which we could Yeagh... what is wrong with ed0, de0, fxp0 etc that needs changing? Is this just a matter of taste or is there more to it? I for one don't see any advantage in eth[0-9] style device naming. Well, for one its sucks trying to get newbies to work out what their network card is called.. Not true IMO. You still need to know what hardware you have before you can build your own kernels etc etc. Also the eth[0..x] thing means you can replace your ethernet card with a new one of a different type without having to look through your config code for references to ed0 or whatever. True. Another thing.. we get to be more Linux like, which is a good thing, right? *duck* Ducking does not help with todays laser-guided precision ammo ;-) ;-) And to answer your question: the day FreeBSD aims to become like Linux I'm likely to install NT. Wilko _ __ | / o / / _ Bulteemail: wi...@yedi.iaf.nl |/|/ / / /( (_) Arnhem, The Netherlands WWW : http://www.tcja.nl __ Powered by FreeBSD __ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/i386/eisa ahb.c
As Jordan K. Hubbard wrote... How Mr. ignoromous Nate could construe this to mean that I was trying to brush something under the rug is beyond me. As I said to Julian, I probably shouldn't have made the committ, but the fact is that I not only left the module on my hotlist, I also immediately brought the potential problem to the attention of the entire list and thence, I think this whole tangled thread can probably be summed up thusly: There will always be those remarking from the sidelines about any change which goes into the FreeBSD source tree, and I do mean ANY change, the amount of commentary usually in inverse proportion to the importance of the change. This is just a given. It's also a given that some of these people will have far less clue than others and even those who have a clue will often express their comments in such a way as to come across as criticising or carping, even though they may not have meant to. There are a lot of engineers here and human interaction is rarely their strong suit. In any case, rather than getting into a protracted furball with each and every commentator and perhaps using inappropriate language in a public mailing list in the process, you've gotta do what pro golfers and ballplayers do - learn to ignore the crowd when it hasn't got Ah, you mean like John McEnroe ? ;-) Wilko _ __ | / o / / _ Bulteemail: wi...@yedi.iaf.nl |/|/ / / /( (_) Arnhem, The Netherlands WWW : http://www.tcja.nl __ Powered by FreeBSD __ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: btokup().. patch to STYLE(9) (fwd)
On Thu, 28 Jan 1999, Julian Elischer wrote: Some people when confronted by people wanting to have extra braces say change style(9). Amazingly there hasn't been a SINGLE comment! (after a whole 8 hours!) julian To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: btokup().. patch to STYLE(9) (fwd)
Julian Elischer writes: Some people when confronted by people wanting to have extra braces say change style(9). Well, here is my change.. You can count my vote. I would also add a paragraph like this: If possible code should complile cleanly with gcc's -Wall flag. Note however that this does not imply that it's OK to eliminate warnings simply by covering them up with typecasts, etc., as that actually does more harm than good. I hope that wording is sufficiently unoffensive to the -Wall haters. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DEVFS, the time has come...
Not true IMO. You still need to know what hardware you have before you can build your own kernels etc etc. Also the eth[0..x] thing means you can replace your ethernet card with a new one of a different type without having to look through your config code for references to ed0 or whatever. True. There's no reason why the devfs code couldn't create the equivalent of symbolic links in its file system so that ed0 and eth0 show up. Yes, I know, this opens up a can of worms when new hardware is added and suddenly the probe order changes such that a newbie finds that eth0 is no longer what he/she/it thought it was going to be. But it's a start. -scooter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
subscribe
To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/i386/eisa ahb.c
Ah, you mean like John McEnroe ? ;-) Specifically NOT like John McEnroe. :-) - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
[no subject]
subscribe To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: No CD-ROM support in boot.flp?
On Wed, 27 Jan 1999, Jordan K. Hubbard wrote: Are there any plans to create another boot disk (cdrom.flp?), 2.88MB in size especially for CD-ROM boots? Yes. Yummy. Reminds me of the atapi.flp fiasco a few years back. :-( Doug White Internet: dwh...@resnet.uoregon.edu| FreeBSD: The Power to Serve http://gladstone.uoregon.edu/~dwhite| www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: indent(1) and style(9) (was: btokup() macro in sys/malloc.h)
Luigi Rizzo lu...@labinfo.iet.unipi.it not speaking about vinum, but to me, the indentation of 8 char and line length of 80 chars are almost mutually exclusive. See e.g. tcp_input.c ip_input.c and many network device drivers as an example -- basically all places where, for efficiency reasons, the code tries to expand in-line various block, According to most of the coding standards I've read, readability (and hence maintainability) come before efficiency. That said, I agree that efficiency _is_ an issue within the kernel's critical paths (the TCP/IP code being one). Judicious use of inline functions (and macros) should help move code to the left - and may even make it more understandable. Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DEVFS, the time has come...
As David Wolfskill wrote... From: Wilko Bulte wi...@yedi.iaf.nl Date: Wed, 27 Jan 1999 23:12:18 +0100 (CET) Yeagh... what is wrong with ed0, de0, fxp0 etc that needs changing? Is this just a matter of taste or is there more to it? I for one don't see any advantage in eth[0-9] style device naming. It's a matter of whether you want the name to reflect the implementation vs. the function. For someone involved in the details of the implementation, being (acutely!) aware of those details can be very important. Guilty your honor ;-) My daily work is in supporting customers, so I can really do without mapping 'convenient names' to physical stuff. For an example: look at the Solaris symlink jungle for device naming. For someone who merely wants to have a certain physical port on the machine connected to a particular network, that level of detail is not always appropriate. It depends on your focus. Agreed. Wilko _ __ | / o / / _ Bulteemail: wi...@yedi.iaf.nl |/|/ / / /( (_) Arnhem, The Netherlands WWW : http://www.tcja.nl __ Powered by FreeBSD __ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: btokup().. patch to STYLE(9) (fwd)
Julian Elischer jul...@whistle.com wrote: Well, here is my change.. I think it's a good move and I'll support it (FWIW). @@ -256,13 +256,23 @@ .Ed .Pp Space after keywords (if, while, for, return, switch). No braces are -used for control statements with zero or only a single statement. +used for control statements with zero or only a single statement unless that +statement is more than a single line in which case they are permitted. ^ I'd prefer `recommended'. And sometime later he wrote: Amazingly there hasn't been a SINGLE comment! (after a whole 8 hours!) I'd treat that as total agreement and commit the change :-). Everyone's probably still recovering from our latest flamefest (how about we get Jordan to create a FreeBSD-flame list to allow people to try out the latest fashion in asbestos clothing and supercharged flamethrowers). Peter -- Peter Jeremy (VK2PJ)peter.jer...@alcatel.com.au Alcatel Australia Limited 41 Mandible St Phone: +61 2 9690 5019 ALEXANDRIA NSW 2015 Fax: +61 2 9690 5982 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DEVFS, the time has come...
On Thu, 28 Jan 1999 sth...@nethelp.no wrote: I agree.. and same thing goes for Ethernet drivers. I actually like the way Linux always has eth0, eth1, ... (which we could Yeagh... what is wrong with ed0, de0, fxp0 etc that needs changing? Is this just a matter of taste or is there more to it? I for one don't see any advantage in eth[0-9] style device naming. I can give you one example. We run a FreeBSD box here which receives all of the traffic (port mirroring) from some Ethernet switches. On the FreeBSD box, we run nnstat, tcpdump etc. for monitoring purposes. Recently I changed some of the DEC 21x4x based cards on this box to Intel cards. Thus the interface names changed from deN to fxpN. This meant we had to update a bunch of Perl and shell scripts. It would have been much nicer (no need to update) if the interfaces were simply named ethN. That's why you don't hard code the interfaces into all the scripts. Instead source a file that gives the definitions ala rc.conf. Personally, I'd also prefer to have IDE disks named daN, but that's another matter... :) -Alfred To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Ne2000 PCI Card
I have 2 cheap 100mbit nics (rj45 only). Both use the ReaTek 8139 chipset (from the best that I can tell). Both are PCI. I've attempted to use both cards in several PCI slots, under 2.2.8 and 3.0 boot floppies, and a 3.0-stable (updated 2 days ago). None of these releases found either card in any situation. I believe the card should be detected as Ed0 (possibly ed1). I have used 3com pci cards in both machines under freebsd sucessfully and the ne2000 cards function under windows and os/2. What can I do? If someone wants to see, I'm willing to give root to a person who wishes to help fix this problem (or make appropriate additions to the driver). Have any changes been applied to 4.0-current which may solve my situation? Tried to get help in #freebsd in efnet, but no-one had suggestions that helped me... (Thanks anyhow Xanne) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Locked at 100% User CPU
In libc_r, I don't think the code in uthread_kern.c's _thread_kern_select() scales at all. As the number of network connections (TCP) to my application grows, I believe this routine takes longer and longer and my CPU goes to 100% user space. Something makes me believe that this routine has an n^2 (or worse) problem. Seems to relate to the number of fd's to select() on. At about 300-400, even a P2 400Mhz gets max'd out and gets nothing done. Anybody have a feeling as to what is wrong here? -Rob To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Ne2000 PCI Card
I have 2 cheap 100mbit nics (rj45 only). Both use the ReaTek 8139 chipset (from the best that I can tell). Both are PCI. They are supported in 4.0-CURRENT by the rl driver. I belive they are also included in 3.0-STABLE, but I'm not sure if they are on the boot floppy. And before using this card, you should consider the following comment from the driver source: * The RealTek 8139 PCI NIC redefines the meaning of 'low end.' This is * probably the worst PCI ethernet controller ever made, with the possible * exception of the FEAST chip made by SMC. The 8139 supports bus-master * DMA, but it has a terrible interface that nullifies any performance * gains that bus-master DMA usually offers. So don't expect too much ;) Blaz Zupan, b...@medinet.si, http://home.amis.net/blaz Medinet d.o.o., Linhartova 21, 2000 Maribor, Slovenia To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Ne2000 PCI Card
On Thu, 28 Jan 1999, Rod Taylor wrote: I have 2 cheap 100mbit nics (rj45 only). Both use the ReaTek 8139 chipset (from the best that I can tell). Both are PCI. I've attempted to use both cards in several PCI slots, under 2.2.8 and 3.0 boot floppies, and a 3.0-stable (updated 2 days ago). None of these releases found either card in any situation. I believe the card should be detected as Ed0 (possibly ed1). I have used 3com pci cards in both machines under freebsd sucessfully and the ne2000 cards function under windows and os/2. Try the rl0 driver: On my system: rl0: RealTek 8139 10/100BaseTX rev 0x10 int a irq 12 on pci0.9.0 -- Brian Buchanan br...@csua.berkeley.edu -- FreeBSD - The Power to Serve! http://www.freebsd.org daemon(n): 1. an attendant power or spirit : GENIUS 2. the cute little mascot of the FreeBSD operating system To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
