Re: FreeBSD's aggressive keyboard probe/attach
On Sat, Aug 11, 2001 at 01:04:07PM -0700, John Polstra wrote: I have no argument about the keyboard probes. I just want to add that in the case of the Belkin OmniView, it should be noted that Belkin shipped a bunch of them with a couple of EPROM chips swapped accidentally. There's a page on the Belkin web site that tells how to check for it and how to fix it. Once I put the chips into the right sockets, my OmniView started working a _whole_ lot better. :-) The weird thing is, it appeared to kind of sort of work most of the time even before. So all along I assumed it was just a poorly designed device, when actually it was just assembled wrong. (I still think it's a poorly designed device, but it's a lot better than it was before I swapped the chips.) I had the same problems, and took my KVM switch apart, expecting to find the chips reversed. They were in fact installed correctly, so at least in my case, the problem exists regardless. If I'm careful to have the KVM switch on the same channel as a booting machine, and leave it on that channel until the probing is done, everything seems to work fine. Otherwise, the keyboard is not detected. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD's aggressive keyboard probe/attach
In article [EMAIL PROTECTED], Jason Evans [EMAIL PROTECTED] wrote: On Sat, Aug 11, 2001 at 01:04:07PM -0700, John Polstra wrote: I just want to add that in the case of the Belkin OmniView, it should be noted that Belkin shipped a bunch of them with a couple of EPROM chips swapped accidentally. I had the same problems, and took my KVM switch apart, expecting to find the chips reversed. They were in fact installed correctly, so at least in my case, the problem exists regardless. If I'm careful to have the KVM switch on the same channel as a booting machine, and leave it on that channel until the probing is done, everything seems to work fine. Otherwise, the keyboard is not detected. Maybe they swapped the labels on the chips too. :-) Seriously, that's really strange. I have all variety of machines hooked up to my Belkin OmniView, including FreeBSD (-current and -stable, i386 and Alpha), Linux, OpenBSD, NetBSD, Tru64, NT, and Win2k, and I don't see any major problems, even using the mouse (no-name 2-button). There is only one thing that drives my the KVM out of its mind: powering down the Alpha. As soon as I do that, the KVM is totally hosed. Even invoking its so-called reset function (pressing both selector buttons simultaneously) doesn't help. As soon as I reboot any machine (even the Alpha) that's connected to the KVM, it's OK again. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD's aggressive keyboard probe/attach
On Sun, Aug 12, 2001 at 02:35:22PM -0700, John Polstra wrote: Maybe they swapped the labels on the chips too. :-) Well, it apparently doesn't fry anything to have the chips reversed, so maybe I should try swapping them just to make sure. =) Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD's aggressive keyboard probe/attach
On Sun, 12 Aug 2001 10:16:47 -0600, Nate Williams wrote:
:Finally, most keyboard/mouse/monitor switches don't work with
:FreeBSD;
This is actually not true. I'd doubt that you've even tried many of them.
Boy, you are on one about me...
I have tried 5 switches. At ClickArray, we have a large number
of Belkin Omniview switches. I have one with firmware version
1.9 at my desk, and freqiently use one with firmware version 1.6
in our lab, with the results I have described.
Strange, as the group at Nokia is running quite a lot of them (Belkin
OmniView and OmniCube) without any problems.
I'm guessing it's operator error. :)
Nate
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
I've seen the 'have to be on the machine while booting' behavior
using a Belkin Omniview Pro switch, which oddly, wasn't a problem
with their OmniCube switch, at least not with my machines. Windows
had as much, or more problems with not having the console on the
booting machine as fbsd though. Again, this is only my (one) data
point.
I finally got fed up with the Belkin, because *windows* keep losing
it's mouse (or instead of just losing it, it would start sending
what appeared to be random button-press events for tracking events...)
and broke down and bought a Raritan KVM. Yep it is/was pricey, but it's
probably one of the purchases I've been happiest with, over the long
run. Video quality ('doze and X displays) is much, *much* better than
the Belkin, and no machine has a problem booting without the console
pointing to it.
Just my $.02.
Thanks,
Mike
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: bash in /usr/local/bin?
I said I'd drop it, but apparently there are people that don't understand the dinosaur mentality of certain organizations such as DOD, DISA/DECC, OSD, DARPA, USA, USN, USAF, and USMC. If it's not in the base setup, on a production box, you can't use it. Everything must be kept in it's ORIGINAL install location, otherwise you MUST justify it and ask DISA/DECC for a waiver, which in itself, is a pain in the ass, and in many cases, not likely to happen due to dinosaur mentality. I now refer you to the recent news concerning the TrustedBSD project. FreeBSD is getting military contracts now. We need to think ahead to the needs of a whole new class of admin and user, and they are in highly restrictive environments that preclude `mv /usr/local/bin/*sh /bin`. I'm sure there are equally restrictive environments for computers and operating systems in *EVERY* country, but I speak from my personal experience with the dinosaurs at DOD. At DOD, *EVERY* copy of FreeBSD will be subject to what I am saying. In the Sun environment in which I did my last DOD contract at, if tcsh wasn't in /bin, I wouldn't have been able to use it. That's how backwards they are. In answer to your statement, some admins can be fired, even arrested and brought up on charges for doing what you suggest. I'm certain that this happens in countries other than America as well. Joseph Mallett wrote: If these admins can't figure out cp `which bash` /bin and then how to add it to etc/shells and chsh root, then I really question if they should be the kind of people that dictate the future of FreeBSD. 0n Sun, Aug 12, 2001 at 04:32:55AM -0500, Jim Bryant wrote: IMHO, all widely accepted shells should be put in /bin jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Buildworld pain in -current
On Sat, Aug 11, 2001 at 05:16:28PM +0930, Daniel O'Connor wrote: I recently had a chance to buildworld on new -stable and -current machines with similar spec'd HW.. The -current build was _slow_ - 10756.71 real 2026.00 user 7814.64 sys vs -stable - 2332.03 real 1193.12 user 425.94 sys GENERIC kernel for both? If so look at all the debugging that is turned on in the -current case to help SMPng debugging until release time. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Buildworld pain in -current
On Sat, Aug 11, 2001 at 05:16:28PM +0930, Daniel O'Connor wrote: I recently had a chance to buildworld on new -stable and -current machines with similar spec'd HW.. The -current build was _slow_ - 10756.71 real 2026.00 user 7814.64 sys vs -stable - 2332.03 real 1193.12 user 425.94 sys Also forgot to mention the difference in default malloc.conf settings. If you are going to benchmark the build of both systems, you need to make sure you are doing it on an even ground (best you can). To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: bash in /usr/local/bin?
On Sun, Aug 12, 2001 at 08:38:56PM +0200, Bernd Walter wrote: Yes the sun packages installs into /bin: ticso@cicely22 uname -a SunOS cicely22 5.8 Generic_108528-01 sun4m sparc SUNW,SPARCclassic ticso@cicely22 which bash /bin/bash ticso@cicely22 file /bin/bash /bin/bash: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, stripped It's not the first time that Unix Vendors do very silly things - just I assume you are referring to the dynamically linked attribute. Note that it is not Sun being silly -- the ELF binary ABI *REQUIRES* dynamic linking. A statically linked ELF binary is not ABI compliant. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: bash in /usr/local/bin?
# Bash has a license which precludes its inclusion as part # of the base system. [Not that I favor more shells on the root file system, but anyway:] What about gcc and grep? Does the license differ or are these not regarded being part of the base system? We would get rid of them if we could. We keep their source code in a ghetto, since we can't. Any company wanting to get rid of all GPL'ed and other restrictively licensed code in a FreeBSD based binary distribution can simply dike the ghetto out of the build tree, and build a still usable system binary from it, with no restrictively licensed code. Changing grep and tar was an incredibly bad decision. It has the distinction that the old, free code is there in the Attic, and can be recovered, if need be. Umm, Terry. There was no 'free' tar. Back in the 386BSD days, when we were looking for a free tar, I contacted Andy Tanenbaum (of Minix) and got permission to use it, since we didn't have one. However, it was voted down as being 'too simple', so we opted for the GNU one. There isn't a BSD or public domain version of tar anywhere to be found, unless you consider 'pax' running in tar emulation mode acceptable. (I certainly don't.) The same story exists with grep. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Anyone working on missing sysv* ipc functionality
On Sun, 12 Aug 2001, Julian Elischer wrote:
...
my guess is that you are
Lets see...
Attached is a first shot to get /compat/linux/usr/bin/ipcs -s working.
I extended sem.h for SEM_STAT and gave it a special handling
in __semctl() to accept a index number.
Please review and commmit if acceptable.
BTW: In sysv_*.c the sysctls got extended to be tunables.
This left the question how (readonly)sysctl vars should get initialised in
modules.
FE: semmni is currently readonly and used on modload time to allocate a scruct.
Because the sysctl var doesn't exist before modload but is used during modload
there is no possibility to preset the value except on compile-time.
One sollution is to use tunables but can they be changed after startup?
BTW2: Is it possible that changing a sysctl(from userland) var calls a
kernel function (maybe for sanity checks)?
Or has the sysct to be of the type SYSCTL_PROC?
Bye!
Michael Reifenberger
^.*Plaut.*$, IT, R/3 Basis, GPS
--- ./i386/linux/linux.h.orig Wed Aug 8 00:09:28 2001
+++ ./i386/linux/linux.hMon Aug 13 00:41:50 2001
@@ -457,4 +457,6 @@
#defineLINUX_SETVAL16
#defineLINUX_SETALL17
+#defineLINUX_SEM_STAT 18
+#defineLINUX_SEM_INFO 19
/*
--- ./kern/sysv_sem.c.orig Sun Aug 12 13:18:34 2001
+++ ./kern/sysv_sem.c Sun Aug 12 23:31:10 2001
@@ -171,4 +171,14 @@
register int i;
+ TUNABLE_INT_FETCH(kern.ipc.semmap, seminfo.semmap);
+ TUNABLE_INT_FETCH(kern.ipc.semmni, seminfo.semmni);
+ TUNABLE_INT_FETCH(kern.ipc.semmns, seminfo.semmns);
+ TUNABLE_INT_FETCH(kern.ipc.semmnu, seminfo.semmnu);
+ TUNABLE_INT_FETCH(kern.ipc.semmsl, seminfo.semmsl);
+ TUNABLE_INT_FETCH(kern.ipc.semopm, seminfo.semopm);
+ TUNABLE_INT_FETCH(kern.ipc.semume, seminfo.semume);
+ TUNABLE_INT_FETCH(kern.ipc.semusz, seminfo.semusz);
+ TUNABLE_INT_FETCH(kern.ipc.semvmx, seminfo.semvmx);
+ TUNABLE_INT_FETCH(kern.ipc.semaem, seminfo.semaem);
sem = malloc(sizeof(struct sem) * seminfo.semmns, M_SEM, M_WAITOK);
if (sem == NULL)
@@ -471,4 +481,21 @@
return (ENOSYS);
+ switch(cmd) {
+ case SEM_STAT:
+ if (semid 0 || semid = seminfo.semmsl)
+ return(EINVAL);
+ semaptr = sema[semid];
+ if ((semaptr-sem_perm.mode SEM_ALLOC) == 0 )
+ return(EINVAL);
+ if ((eval = ipcperm(p, semaptr-sem_perm, IPC_R)))
+ return(eval);
+ if ((eval = copyin(arg, real_arg, sizeof(real_arg))) != 0)
+ return(eval);
+ eval = copyout((caddr_t)semaptr, real_arg.buf,
+ sizeof(struct semid_ds));
+ rval = IXSEQ_TO_IPCID(semid,semaptr-sem_perm);
+ goto out;
+ }
+
semid = IPCID_TO_IX(semid);
if (semid 0 || semid = seminfo.semmsl)
@@ -602,4 +629,6 @@
return(EINVAL);
}
+
+out:
if (eval == 0)
--- ./kern/sysv_shm.c.orig Sun Aug 12 13:18:43 2001
+++ ./kern/sysv_shm.c Sun Aug 12 21:11:36 2001
@@ -716,4 +716,10 @@
int i;
+TUNABLE_INT_FETCH(kern.ipc.shmmaxpgs, shminfo.shmall);
+shminfo.shmmax = shminfo.shmall * PAGE_SIZE;
+TUNABLE_INT_FETCH(kern.ipc.shmmin, shminfo.shmmin);
+TUNABLE_INT_FETCH(kern.ipc.shmmni, shminfo.shmmni);
+TUNABLE_INT_FETCH(kern.ipc.shmseg, shminfo.shmseg);
+TUNABLE_INT_FETCH(kern.ipc.shm_use_phys, shm_use_phys);
shmalloced = shminfo.shmmni;
shmsegs = malloc(shmalloced * sizeof(shmsegs[0]), M_SHM, M_WAITOK);
--- ./sys/sem.h.origSun Aug 12 23:17:32 2001
+++ ./sys/sem.h Mon Aug 13 00:40:50 2001
@@ -59,4 +59,6 @@
#define SETVAL 8 /* Set the value of semval to arg.val {ALTER} */
#define SETALL 9 /* Set semvals from arg.array {ALTER} */
+#define SEM_STAT 10 /* Like IPC_STAT but treats semid as sema-index*/
+#define SEM_INFO 11 /* for future use */
/*
--- ./compat/linux/linux_ipc.c.orig Sat Aug 4 17:49:33 2001
+++ ./compat/linux/linux_ipc.c Mon Aug 13 00:45:27 2001
@@ -41,4 +41,34 @@
#include compat/linux/linux_util.h
+struct linux_seminfo {
+int semmap;
+int semmni;
+int semmns;
+int semmnu;
+int semmsl;
+int semopm;
+int semume;
+int semusz;
+int semvmx;
+int semaem;
+};
+
+struct linux_shminfo {
+int shmmax;
+int shmmin;
+int shmmni;
+int shmseg;
+int shmall;
+};
+
+struct linux_shm_info {
+int used_ids;
+unsigned long shm_tot; /* total allocated shm */
+unsigned long shm_rss; /* total resident shm */
+unsigned long shm_swp; /* total swapped shm */
+unsigned long swap_attempts;
+unsigned long swap_successes;
2nd data point for keyboard probes (was Re: FreeBSD's aggressive keyboard probe/attach)
I've seen the 'have to be on the machine while booting' behavior using a Belkin Omniview Pro switch, which oddly, wasn't a problem with their OmniCube switch, at least not with my machines. Windows had as much, or more problems with not having the console on the booting machine as fbsd though. Again, this is only my (one) data point. Make that two data points, I don't think you're alone in this observation. I finally got fed up with the Belkin, because *windows* keep losing it's mouse (or instead of just losing it, it would start sending what appeared to be random button-press events for tracking events...) and broke down and bought a Raritan KVM. You mean you got tired of the Ctl+esc, Up arrow, Enter, Enter key sequence to get the mouse back? I wonder why ;~) None the less, having to have the console active for the system while the BIOS OS probe the keyboard is a pain when managing a large number of systems. We eventually made a policy that required the use of a laptop + serial cable anyone when you went to one of the data centers to do some administration of the systems (downtime for a keyboard wasn't an option). -sc -- Sean Chittenden PGP signature
Re: bash in /usr/local/bin?
As a preface to this whole thing, I find it higly amusing that you are sending this mail from a Linux box. Of course, for that matter, so am I. (I'm planning on changing that soon.) On Sun, 12 Aug 2001, Jim Bryant wrote: I said I'd drop it, but apparently there are people that don't understand the dinosaur mentality of certain organizations such as DOD, DISA/DECC, OSD, DARPA, USA, USN, USAF, and USMC. If it's not in the base setup, on a production box, you can't use it. Everything must be kept in it's ORIGINAL install location, otherwise you MUST justify it and ask DISA/DECC for a waiver, which in itself, is a pain in the ass, and in many cases, not likely to happen due to dinosaur mentality. You said it yourself. They are a dinosaur. Why should be drag ourselves back to the paleolithic and cater to a very specific problem in our base tree? bash is a nice shell. I use it as my normal shell, but when I drop to single user mode, I *always* end up using /bin/sh. I'm not a fan of csh (tcsh isn't bad though) and I only write shell scripts in /bin/sh. Besides, how often do you need to drop to single user mode and *really* need bash? I now refer you to the recent news concerning the TrustedBSD project. FreeBSD is getting military contracts now. We need to think ahead to the needs of a whole new class of admin and user, and they are in highly restrictive environments that preclude `mv /usr/local/bin/*sh /bin`. And those people that are working there are probably programming in COBOL and Fortran. I'm sure there are equally restrictive environments for computers and operating systems in *EVERY* country, but I speak from my personal experience with the dinosaurs at DOD. At DOD, *EVERY* copy of FreeBSD will be subject to what I am saying. In the Sun environment in which I did my last DOD contract at, if tcsh wasn't in /bin, I wouldn't have been able to use it. That's how backwards they are. In answer to your statement, some admins can be fired, even arrested and brought up on charges for doing what you suggest. I'm certain that this happens in countries other than America as well. Again, this is a problem for you and the DOD to sort out. It should be of no concern to the project. -gordon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD's aggressive keyboard probe/attach
Here is the _precise_ problem with older firmware: The Belkin KVM switch uses the on-off-on or off-on-off of this LED to signal a port change character is coming next, and times out the port change request only after a little while. Ah, so the problem is actually a design defect in the Belkin switch. Nice to have that part confirmed. The fundamental problem here is that FreeBSD _resets_ a keyboard which has already been correctly reset by the BIOS, if it is present. You can't be sure of this. Just as we reset everything else we talk to, we reset the keyboard. Specific examples where *not* resetting things gets us into trouble can typically be found by looking for when I reboot from Windows XYZ doesn't work. The FreeBSD keyboard detection is another matter; FreeBSD will assume that there is no keyboard, and try to helpfully drop you into serial console mode. No it won't, unless you explicitly configure it. Some of this _used_ to be mitigated by checking for the extended keyboard bit in the keyboard identify BIOS call, but this was a problem for people with antique keyboards. This is not the problem, as I have already mentioned in another message. BIOS vendors have *stopped* setting this bit. My suggestion for a probe in this case would be to set up a different handler for the reset signal, and then ask the keyboard to send the reset signal. If it does, then there is a keyboard present. Keyboard probing is a dead loss, which is why we don't do it by default. More ideally, the FreeBSD box would detect whether or not the video card had been disabled, and use _that_ to decide whether or not to use a keyboard. It would become the job of the video driver -- be it a regular driver, or be it an LCD driver -- to make the distinction. There is no standardised way of detecting whether a display has been disabled. Absolutely ideally, FreeBSD would come up with the boot code on _both_ (this is an option), and then be told by the user to not use one of them -- or boot using _both_, until told to do otherwise. We've tried this already; people didn't like it. This would _also_ solve the Alpha serial console dance. Actually, it wouldn't, since we use the SRM console for quite a ways, and SRM doesn't do multi-source console I/O. (And when you have a version of SRM that allows you to 'pull' the console by sending a few keystrokes, you can't work out where it's actually directed anyway.) -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD's aggressive keyboard probe/attach
On 12-Aug-01 Joe Kelsey wrote: Thank you very much for the clear and cogent explanation of your philosophy of the psm code. Could I suggest that you copy the aforementioned e-mail directly into the psm.c file for everyone to see in posterity? Also, I have a fundamental problem with device flags. I believe that every situation which uses device flags should instead use sysctl variables, allowing easy manipulation at run-time. Of course, there are no doubt situations not addressable at run-time, but these should be the rare special cases where a driver flag is used. Patches accepted. This is a volunteer project. If you want to be productive, work up a device attribute interface that allows devices to query attributes and allows devices to be notified when outside events change their attributes. You should probably use kernel environment variables (like the hints we have now) for setting attributes from the loader, and then use sysctl's to back the runtime interface (IMO). I realize the user side of the attributes is up for debate, but working on solving this problem is much more problem than complaining that people aren't giving you the free gift you want. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD's aggressive keyboard probe/attach
On 12-Aug-01 Terry Lambert wrote: Mike Smith wrote: :Finally, most keyboard/mouse/monitor switches don't work with :FreeBSD; This is actually not true. I'd doubt that you've even tried many of them. *sigh* It seems no one has investigated why we probe keyboards at all. Maybe if people would do a little research, they would _learn_ something. Assuming that we always have PS/2 keyboards present breaks the case of people who use *shock* non-PS/2 keyboards like USB keyboards. Now, I'm sure that you think that everyone should use PS/2 keyboards and that anyone who doesn't is just absolute pure scum of the earth, but I don't share that same view. :-P Seriously, if you go up to a FreeBSD box and hotplug a USB keyboard (which was _designed_ for hotplug) it will work just fine. Now, there are a couple of different ways to fix the problem: 1) Implement probing/detection for PS/2 keyboards post-boot. You can hack this by having the atkbd0 driver always attach to IRQ 1, but not create and export a kbd0 syscons keyboard driver until it gets an interrupt event from the keyboard. 2) Rewrite the syscons keyboard layer so that we don't have a primary keyboard that is always the current keyboard, but instead make it accept input from all keyboards currently plugged into the system. With this you could go back to assuming a PS/2 keyboard is always around as a hack. Obviously Windows can handle USB keyboards, so why don't you put your money where your mouth is and make FreeBSD work fine on hardware that Windows works on. Patches accepted. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD's aggressive keyboard probe/attach
On 12-Aug-01 Terry Lambert wrote: The FreeBSD keyboard detection is another matter; FreeBSD will assume that there is no keyboard, and try to helpfully drop you into serial console mode. Some of this _used_ to be mitigated by checking for the extended keyboard bit in the keyboard identify BIOS call, but this was a problem for people with antique keyboards. Umm, this is the -P flag to boot2 which is no longer on by default. Not a kernel issue. My suggestion for a probe in this case would be to set up a different handler for the reset signal, and then ask the keyboard to send the reset signal. If it does, then there is a keyboard present. Yeah, and resetting the controller works fine on machines that don't have keyboards, so it returns false positives. More ideally, the FreeBSD box would detect whether or not the video card had been disabled, and use _that_ to decide whether or not to use a keyboard. It would become the job of the video driver -- be it a regular driver, or be it an LCD driver -- to make the distinction. This might be practical except that lots of motherboards ship with built-in video these days. Absolutely ideally, FreeBSD would come up with the boot code on _both_ (this is an option), and then be told by the user to not use one of them -- or boot using _both_, until told to do otherwise. This would _also_ solve the Alpha serial console dance. What dance? Works great for me. If SRM uses serial console, so does FreeBSD. If SRM uses vidconsole, so does FreeBSD. In fact, this is the _only_ way it can work on the Alpha since SRM just gives you one console device handle and one boot device handle. Have you actually used an Alpha before? :-P -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: bash in /usr/local/bin?
On Sun, Aug 12, 2001 at 04:54:08PM -0700, Gordon Tetlow wrote: FreeBSD is getting military contracts now. We need to think ahead to the needs of a whole new class of admin and user, and they are in highly restrictive environments that preclude `mv /usr/local/bin/*sh /bin`. And those people that are working there are probably programming in COBOL and Fortran. Sigh. A stupid language war troll. You haven't looked at the Fortran language since 1977 have you? Back to the topic at hand, bash isn't in the root filesystem. Get over it. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD's aggressive keyboard probe/attach
On 13-Aug-01 John Baldwin wrote: runtime interface (IMO). I realize the user side of the attributes is up for debate, but working on solving this problem is much more problem than complaining that people aren't giving you the free gift you want. s/problem/productive/2 -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: bash in /usr/local/bin?
On Monday 13 August 2001 3:08 am, The Anarcat wrote: [This email contains coarse language due to the absurdity of the thread level we're in. My apologies to those offended. Also, my apologies to the author of the original mail. You have triggered very sensitive areas of my mind. :)] Swearing adds absolutely nothing to your argument, you've devalued your own opinion by giving the impression you're incapable of expressing yourself without resorting to swearing. I personally got sick of it a short way down and gave up reading. -- Andrew Boothman [EMAIL PROTECTED] http://sour.cream.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Documentation in FreeBSD
OK, so we have beaten the psm and keyboard code to death. The entire point that I have been trying to make in this discussion is that it is imperative to document design decisions somewhere that is likely to survive changes in maintainer. I have been working as an administrator and programmer for many years. In that time, it has become quite clear to me that the largest effort in any multi-year, multi-person programming effort is documenting what you do in order that those that follow you (or even yourself, several years hence) can figure out what you did and why you did it. The most clever hack that you implement becomes the most obscure, opaque code if you only instrument it with cryptic one-lin comments. I am not speaking against anyone who has put effort into writing and maintaining the excellent code that is FreeBSD. I appreciate the code and all of the effort it represents. However, the constant clamor of the denizens of this list who constantly har if you don't like it, submit a patch is extremely annoying. You cannot submit a patch to opaque code without expending massive amounts of effort to figure out the opacity. Please, all I am asking for is that, if there is any long dicsussion about the pros and cons of some design decision, the person responsible for maintaining the code in question should also be responsible for immortalizing the discussion in the code. Either simply copy the most relevant e-mail into a comment or summarize the comments, with, perhaps, a pointer to the e-mail subject line of the discussion to make searching the archives easier on those who follow. What I am pleading for is nothing more than any commercial software house requires of its programmers. Document the design in order that maintainence is easier. Personally, I prefer to use literate programming techniques for this, but that is not possible for many OS functions. Certainly, we could adopt some sort of standard practice to embed design comments in the code. I personally prefer to over-comment as it is hard to determine exactly what someone needs 5 years from now to fix a problem. Of course, illiterate comments can sometimes be worse than no comment, but that is a discussion for another forum. There is a lot of good discussion that goes on on this and other lists that needs to somehow make it into the code or into a separate documentation area (section 4 pages? info docs? articles?) /Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Netiquette (Was: Re: FreeBSD's aggressive keyboard probe/attach)
On Sun, 12 Aug 2001, Warner Losh wrote: A word about tone. If you were to get as in my face about, say, pccard, as you about the psm driver, I'd certainly be ill inclined to provide you with what you want. Good Tone: Say Warner, why do you bother turning off the power after you suspend a socket. Shouldn't the power routines take care of that? Is there something subtle that's going on? Maybe a comment is in order? Bad Tone: Please explain the pros and cons for turning the power off after suspending a socket. I really want to know. Why did they do this? Didn't the coder trust the power routines? The least he could have done was include a comment. Was there some long discussion that I missed? See the difference? The first tone is friendly, suggesting that something in the code might be unclear. The second seems to imply that I'm a moron for not documenting every trivial solution with a 20 page thesis on why it is good or bad to do. This is such a great example of how tone can come across poorly in a text medium. I doubt (hope) that Joe didn't mean to come across as that. But tone in email is so often inferred based on the readers own moods, that phrasing email becomes much more important so as to not give the reader the wrong impression. This should be required reading for anyone considering posting to a FreeBSD mailing list. -gordon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Good Tone vs. Bad tone
Warner Losh writes: Good Tone: Say Warner, why do you bother turning off the power after you suspend a socket. Shouldn't the power routines take care of that? Is there something subtle that's going on? Maybe a comment is in order? Bad Tone: Please explain the pros and cons for turning the power off after suspending a socket. I really want to know. Why did they do this? Didn't the coder trust the power routines? The least he could have done was include a comment. Was there some long discussion that I missed? See the difference? The first tone is friendly, suggesting that something in the code might be unclear. The second seems to imply that I'm a moron for not documenting every trivial solution with a 20 page thesis on why it is good or bad to do. I am sorry if you interpreted my message as implying that you are a bad coder or even a moron. I was not thinking either when I wrote it. However, I do not think your example is a good one in explaining good versus bad tone. I am sorry if my opinion offends you. You do excellent work on FreeBSd, as everyone else I have ever encountered who spends so much time improving the code base also does excellent work. I am trying to make a point about documentation and its role in helping to move forward a public-participation project such as FreeBSD. Terry was trying to make a similar point inhis Go SOLO 2 posts about the man pages. Anyone who wants to help out is met by several road blocks. First, there is a severe problem with understanding the existing code base. This problem is common in most commercial software projects, although most companies make some effort at documenting the design, at least initially. Documenting changes to the design is a real effort. I am personally a fan of tying the design documentation and code closely together through design commentary in the code, preferably using Literate Programming techniques. Then, there is simply the problem of written communication not being semantically expressive enough (lack of tone to express emotion, and emoticons do not do a very good job here, ;-)). It is easy to become intimidated or to inadvertently intimidate others through this medium of e-mail. These roadblocks tend to get worse with the barrage of posters who simply keep shouting send patches. You cannot patch what you don't understand and you cannot understand what is not documented. Yes, if, indeed, the disable/enable pair is time consuming, then it should be protected by code that tries to make sure it is not called repeatedly. The simplest solution is a flag or counter to prevent recursive calls. Also, a timer can prevent calling it in rapid succession. If I can understand the reasons for the cryptic XXX hack comment, I can formulate alternate proposals for potential solutions. I certainly want to be a constructive member of the community, if at all possible. Right now I am just trying to learn and point out the road blocks as I encounter them. If someone chooses to perceive my documentation of my path to enlightenment as criticism of themselves, that is not my point, and I am sorry that you take it as a personal critique. Enough rampling for now. /Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Documentation in FreeBSD
On Sun, Aug 12, 2001 at 07:51:05PM -0700, Joe Kelsey wrote: OK, so we have beaten the psm and keyboard code to death. The entire point that I have been trying to make in this discussion is that it is imperative to document design decisions somewhere that is likely to survive changes in maintainer. ... What I am pleading for is nothing more than any commercial software house requires of its programmers. And *PAYS* its programmers to do. This is the point you are missing. If you were to commercially sponsor some design docs, I'm sure we can get them written. Certainly, we could adopt some sort of standard practice to embed design comments in the code. I personally prefer to over-comment as it is hard to determine exactly what someone needs 5 years from now to fix a problem. Send patches. You wanted some of the PSM comments added to the code -- send a patch that adds the ones you think would have helped you. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: bash in /usr/local/bin?
Not to be a pain, but can you wrap lines at a more standard 74 columns as opposed to whatever you are currently wrapping them at? Thanks. On Sun, 12 Aug 2001, Jim Bryant wrote: Gordon Tetlow wrote: As a preface to this whole thing, I find it higly amusing that you are sending this mail from a Linux box. Of course, for that matter, so am I. (I'm planning on changing that soon.) Excuse me? FreeBSD wahoo.kc.rr.com 5.0-CURRENT FreeBSD 5.0-CURRENT #18: Fri Aug 10 16:51:25 CDT 2001 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/WAHOO i386 When Netscape comes out with support for FreeBSD again, I'll run native, until then, I, like everyone else using freebsd am stuck using netscape in the COMPATLINUX construct. Please don't make assumptions about an operating environment without understanding the problems of living within that environment. Ah, my apologies. It's much less amusing now. Also, dinosaurs or not, DOD is now an INVESTOR in the FreeBSD system. Name any other group besides maybe BSDI that has provided $1.4 million [USD] to the project. Okay, I don't recall the FreeBSD Foundation getting $1.4 mil. I know that the DOD is sponsoring some TrustedBSD stuff, but where exactly is the money going? We should look towards making FreeBSD the open-source OS of choice in the DOD environment, in which Linux has already made major inroads where FreeBSD isn't even allowed to tread yet. Actually, it is up to us to resolve this. I don't think you understand how DOD operates. The vendor makes the changes, not DOD. Not the admin. Again, I don't see why we should cater to one specific group of people and let them dictate the direction of the project. Another priority item should be making sure we are compatible with such things as the latest versions of Oracle, etc... This is an area in which we can compete head-to-head with the high-dollar stuff. Well, considering that Oracle doesn't publish *anything* for FreeBSD, I doubt there is anything we can do about it. Veritas NetBackup has a FreeBSD client (no server). IBM DB2 has no FreeBSD support. Heck, as you point out Netscape doesn't even make FreeBSD binaries. And you know what? There's squat that the project can do about it. We can't make companies support FreeBSD if they don't want to spend the resources for it. Also, I havn't worked for DOD in a long time, but I have done recent contracts with them, and understand firsthand the BS involved in having to do without tools all unix people, including myself, consider standard, that are not allowed because it's not part of the base install. Moving the non-GPL shells to /bin is a trivial request that can solve problems that you obviously don't understand. Um, bash is GPL. The reason for not putting it in the base system is due to licensing restrictions. We try to use as few GPL'd pieces as possible. After seeing that grep is a GNU tool, I'm almost tempted to try writing a BSD-style grep for the fun/exercise of it. DOD will is a vast new market for FreeBSD, and if we don't think ahead now and consider what will make admins recommend FreeBSD over Linux, Solaris, or HP-UX, then we'll never reach the kind of market penetration that Linux, Solaris, and HP-UX have in the DOD market. Key to this is an admin-friendly environment designed to get around the pre-cambrian attitudes that prevent DOD admins from using standard tools just because it's in the wrong place on the disk array or because it's considered a third-party option, or even worse: freeware [h! step away from the keyboard, son. you going to prison, boy!]. Read my lips (er text, whatever). Bash and other shells are not going to make it into the base FreeBSD OS. The increasing code base does worry me though. I'm not a big fan of adding more and more functionality to the base. I like the very functional, very useful codebase that we currently have. You can do alot more with a base FreeBSD installation than you can with a base Solaris installation (like compile things). I'm more for an evolutionary unix where the idea of what's standard changes to reflect the needs of it's admins and users in diverse environments. Then feel free to take FreeBSD, tweak it and publish it as DODBSD. By all means, the license lets you do it. I may not be one of the big movers, but I think this is why I do what I can to help out with -CURRENT, to move forwards meeting the needs, instead of going nowhere due to outdated beliefs oh, but that belongs in /usr/local/bin. If something after years of use becomes a standard tool, it needs to be moved into the base distribution. I give perl as a prime example of one time that this actually happened, despite the arguments for or against perl, it *IS* a standard tool, and it *IS* expected to be available. And for 99.999% of the users, they could care less if it's in /usr/local or in / And for things that are not in the base system, they belong in /usr/local. That's
Re: bash in /usr/local/bin?
On Sun, 12 Aug 2001, Steve Kargl wrote: On Sun, Aug 12, 2001 at 04:54:08PM -0700, Gordon Tetlow wrote: FreeBSD is getting military contracts now. We need to think ahead to the needs of a whole new class of admin and user, and they are in highly restrictive environments that preclude `mv /usr/local/bin/*sh /bin`. And those people that are working there are probably programming in COBOL and Fortran. Sigh. A stupid language war troll. You haven't looked at the Fortran language since 1977 have you? I forgot to add sarcasm /sarcasm around that. Actually, ADA would probably be more correct. I was born in 1978 btw. -gordon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: bash in /usr/local/bin?
On Sun, Aug 12, 2001 at 09:20:59PM -0700, Gordon Tetlow wrote: After seeing that grep is a GNU tool, I'm almost tempted to try writing a BSD-style grep for the fun/exercise of it. Rather than do that, continue the development of /usr/ports/textproc/freegrep, which was started for exactly the above reason. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: bash in /usr/local/bin?
On Sun, Aug 12, 2001 at 08:15:15PM -0500, Jim Bryant wrote: Actually, it is up to us to resolve this. I don't think you understand how DOD operates. The vendor makes the changes, not DOD. Not the admin. Sigh. If an admin cannot handle /bin/sh long enough to get /usr mounted, they have no business being an admin. And Yes, I am a 100% bash user (I'm also the guy that brought you tcsh in the base system) Bash is my shell, and toor's shell. When I want bash single user, I answer the question of which shell with /usr/local/bin/bash as my / and /usr are the same (there! problem solved for the guy that started this thread). On machines I deal with that have seperate / and /usr, I take the default of /bin/sh and then do the: mount /usr /usr/local/bin/bash dance. Now that isn't such a hard dance now is it? I live it, it can be done. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: bash in /usr/local/bin?
On Sun, Aug 12, 2001 at 09:20:37PM -0700, Gordon Tetlow wrote: After seeing that grep is a GNU tool, I'm almost tempted to try writing a BSD-style grep for the fun/exercise of it. lizzy:/usr/ports/textproc/freegrep# cat pkg-descr This is an implementation of grep(1) intended as a replacement for FreeBSD's GNU grep. GNU grep falls under GPL, while this implementation is under a BSD-friendly licence. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: bash in /usr/local/bin?
On Sun, Aug 12, 2001 at 10:08:40PM -0400, The Anarcat wrote: And FreeBSD is the *vendor*? I don't think so. At least I don't hope so. Actually we *are*. Seen those ISO's up on ftp.freebsd.org?? -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: _sigprocmask in malloc.c causes full file table?
On Sat, Aug 11, 2001 at 05:25:42PM -0700, Terry Lambert wrote: It's like trying to find something in hierachically organized GNU info documentation: redundancy is useful, and try to find __PRETTY_FUNCTION__ in the gcc documentation, when you need to read the man page carefully to find the info reference, and then need to run the info program instead to find the real documentation, and then either know emacs, or linearly tree search through 37 documents (yes, I counted), to find something that should be on the cpp man page. ^^ The GCC developers want the manpages to die. If you like, I can just rm them. But I'm not going to write replacements. Fight this battle with the GCC developers, not FreeBSD people. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD's aggressive keyboard probe/attach
On Sat, 11 Aug 2001, Terry Lambert wrote: Finally, most keyboard/mouse/monitor switches don't work with FreeBSD; for example, the Belkin console extender that uses the ethernet cable doesn't work at all (it's the best one out there), I'm using a Cybex KVM-over-CAT5 extender with a cheap 4-port Belkin OmniCube KVM switch on one end (my desk) and a much more expensive 8-port dual-user Belkin (OmniView?) KVM switch on the other end (the server closet) attached to three FreeBSD servers and one NT box. I only use keyboard and video for the FreeBSD boxes, but that much has always worked perfectly. Occasionally I'll have mouse sync problems when I switch between FreeBSD and NT when the NT box has had difference mice (wheel vs. non-wheel MS mice, apparently) used on it via the dual-user KVM switch. NT seems to handle that case fairly well by resetting the PS/2 port and/or the mouse (not sure which) and redetecting the mouse type. FreeBSD doesn't like when NT has done that to the mouse, though, and spews sync errors when I switch back. Usually I can kill moused and restart it to fix the problem. and the local wiring (non-ethernet version) of the Belkin OmniView switches work if the FreeBSD mouse/keyboard is selected at boot time, so that the aggressive probe/attach can satisfy itself. That is the KVM switch's fault, not FreeBSD's. On all but the most expensive KVM switches which offer true keyboard and mouse emulation on all ports, even NT (or actually the BIOS, I assume) can fail to enable keyboard and mouse support in that case. The dual-user Belkin OmniView seems to handle this correctly. I can't recall any problem booting FreeBSD on it even when its console isn't active. Belkin went out of its way to support FreeBSD specifically, actually: their firmware version 1.9 fixes the local wiring switches, so that they can pass FreeBSD's aggressive probe, even if the FreeBSD mouse/keyboard is _not_ selected. Hmm... I'll have to check, maybe thats why mine works. :-) -- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The fastest and most stable server OS on the planet - Available for IA32 (Intel x86) and Alpha architectures - IA64 (Itanium), PowerPC, and ARM architectures under development - http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: bash in /usr/local/bin?
On Sun, 12 Aug 2001 17:04:01 -0500 Jim Bryant [EMAIL PROTECTED] wrote: JB I said I'd drop it, but apparently there are people that don't understand the dinosaur mentality of certain organizations such as JB DOD, DISA/DECC, OSD, DARPA, USA, USN, USAF, and USMC. JB JB If it's not in the base setup, on a production box, you can't use it. Everything must be kept in it's ORIGINAL install location, Th obvious solution to this is a 'Military' switch in sysinstall that sets PREFIX to / for all ports. -- Directable Mirrors - A Better Way To Focus The Sun http://www.best.com/~sohara To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
