RE: userland ppp - startup
> -Original Message- > From: Josef Karthauser [SMTP:[EMAIL PROTECTED]] > Sent: Wednesday, July 07, 1999 1:22 PM > To: Ladavac Marino > Cc: Brian Somers; Mark Thomas; [EMAIL PROTECTED]; Wayne > Self > Subject: Re: userland ppp - startup > > On Wed, Jul 07, 1999 at 12:20:35PM +0200, Ladavac Marino wrote: > > [ML] Don't know about sppp, but the only halfway secure way to > > keep this sensitive data is in a file readable by root, and having > the > > program which needs it setuid root. Sounds a lot like > > /etc/ppp/ppp.conf, doesn't it? > > > > The secure way would be not keeping the info at all :) > > It does :) That said doesn't sysinstall using ppp to do a net > install? > How does it setup username/password, etc. [ML] It asks for it in a dialog box, IIRC (never having used it :) /Marino > Joe > -- > Josef Karthauser FreeBSD: How many times have you booted today? > Technical Manager Viagra for your server > (http://www.uk.freebsd.org) > Pavilion Internet plc. [[EMAIL PROTECTED], [EMAIL PROTECTED], > [EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: userland ppp - startup
> -Original Message- > From: Josef Karthauser [SMTP:[EMAIL PROTECTED]] > Sent: Wednesday, July 07, 1999 11:53 AM > To: Ladavac Marino > Cc: Brian Somers; Mark Thomas; [EMAIL PROTECTED]; Wayne > Self > Subject: Re: userland ppp - startup > > On Wed, Jul 07, 1999 at 11:46:27AM +0200, Ladavac Marino wrote: > > > > > Something like this should do it. It may be nice to also allow > the > > > authname/authkey to be specified on the command line so that they > > > can easily be set in rc.conf, by hand or by sysinstall. > > > > > [ML] You do not really want these on the command line for > > everyone to see with ps. (nor in rc.conf for everyone to see with > e.g. > > cat) > > Hmm... how to do this then? The sppp setup code in rc.* allows > username/password > to be specified. Can it be done in the environment then? (If rc.conf > is visable > then the sppp config gives usernames and passwords away as it stands > today.) [ML] Don't know about sppp, but the only halfway secure way to keep this sensitive data is in a file readable by root, and having the program which needs it setuid root. Sounds a lot like /etc/ppp/ppp.conf, doesn't it? The secure way would be not keeping the info at all :) /Marino > Joe > -- > Josef Karthauser FreeBSD: How many times have you booted today? > Technical Manager Viagra for your server > (http://www.uk.freebsd.org) > Pavilion Internet plc. [[EMAIL PROTECTED], [EMAIL PROTECTED], > [EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: userland ppp - startup
> -Original Message- > From: Josef Karthauser [SMTP:[EMAIL PROTECTED]] > Sent: Wednesday, July 07, 1999 11:38 AM > To: Brian Somers > Cc: Mark Thomas; [EMAIL PROTECTED]; Wayne Self > Subject: Re: userland ppp - startup > > Something like this should do it. It may be nice to also allow the > authname/authkey to be specified on the command line so that they > can easily be set in rc.conf, by hand or by sysinstall. > [ML] You do not really want these on the command line for everyone to see with ps. (nor in rc.conf for everyone to see with e.g. cat) /Marino > Joe > -- > Josef Karthauser FreeBSD: How many times have you booted today? > Technical Manager Viagra for your server > (http://www.uk.freebsd.org) > Pavilion Internet plc. [[EMAIL PROTECTED], [EMAIL PROTECTED], > [EMAIL PROTECTED]] << File: rc.conf-patch.txt >> << File: > rc.network-patch.txt >> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Building www/en
> -Original Message- > From: Peter Jeremy [SMTP:jere...@gsmx07.alcatel.com.au] > Sent: Monday, June 07, 1999 11:41 PM > To: freebsd-current@FreeBSD.ORG > Subject: Building www/en > > Part of my regular rebuild is a `cd www/en; make -DENGLISH_ONLY' > > My question is: How do I create /usr/local/share/sgml/docbook/catalog > ? > It doesn't exist in any of the ports. > [ML] IIRC, mkdir /usr/local/share/sgml/docbook/catalog should suffice. It's been a while, though, since I've had a FreeBSD box with SGML toolchain. > Peter > > > 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
RE: wide char support
> -Original Message- > From: Chuck Robey [SMTP:chu...@picnic.mat.net] > Sent: Monday, June 07, 1999 6:32 PM > To: ito...@iijlab.net > Cc: David E. Cross; freebsd-current@FreeBSD.ORG > Subject: Re: wide char support > > May you both live in interesting times! [ML] No, not that curse! Everyone, flee the Agatean Empire! /Marino To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
RE: IRQ sharing with newbus
> -Original Message- > From: Garrett Wollman [SMTP:woll...@khavrinen.lcs.mit.edu] > Sent: Wednesday, June 02, 1999 9:13 PM > To: Bruce Evans > Cc: d...@nlsystems.com; woll...@khavrinen.lcs.mit.edu; > curr...@freebsd.org; new...@atdot.dotat.org > Subject: Re: IRQ sharing with newbus > > < > said: > > >> But the sio non-multiport stuff should be able to use RF_TIMESHARE. > -- > >> If I'm not using my serial port, I should be able to use my > >> infrared > > > Preemptive timesharing would be hard to implement reasonably for > irqs. > > A uniform timeslice would have to be 86 usec to work properly for > > unbuffered sio devices at 115200 bps. > > You're talking intervals about six orders of magnitude smaller than I > am. [ML] If I understand you correctly, you want to resource track the IRQ's so if one device that uses one particular IRQ is active, another one cannot be activated? Example: I have a modem on sio1 and digicam on sio3 (both on IRQ3). I can either use my modem or download the photos, but not both at the same time. That would be nice. I don't known whether this is already supported as I don't have sio3 :) (I don't have sio1 either :) /Marino > -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 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
RE: FTP passive mode - a new default?
> -Original Message- > From: Nick Hibma [SMTP:nick.hi...@jrc.it] > Sent: Wednesday, May 26, 1999 1:38 PM > To: Jordan K. Hubbard > Cc: curr...@freebsd.org > Subject: Re: FTP passive mode - a new default? > > > Is there a list of pro-/cons- available? > > - it is slower, but by how much and on which types of lines (low/high > latency, low/high bandwidth)? [ML] same speed. passive means that the client (and not the server) opens the data connection. advantageous for people sitting behind packet or nat firewalls. > - any (windows) tools not supporting it? [ML] this is an ftp client request. some ancient ftp servers may not support passive data connections, but I haven't seen one of those in a long while. I don't know whether the windows ftpd is incapable of passive mode. actually, if the passive mode default is implemented correctly, the client should send PASV and if the server accepts it proceed, otherwise remain in active mode (and if you are behind a nat or a firewall you are no worse off than you already were). /Marino > Nick > > > Unless I hear unanimous fierce outcry against it, I'm strongly > > considering making FTP_PASSIVE_MODE obsolete by virtue of being the > > default for all tools/libraries which currently examine it. > > FTP_ACTIVE_MODE will be the new flag for toggling the previous > > behavior. > > > > Given the state of the Internet today, I think this is purely a > > sensible change in defaults. Comments? > > > > - Jordan > > > > > > To Unsubscribe: send mail to majord...@freebsd.org > > with "unsubscribe freebsd-current" in the body of the message > > > > > > -- > ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy > > > > 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
RE: priorities
> -Original Message- > From: Doug White [SMTP:dwh...@resnet.uoregon.edu] > Sent: Sunday, May 23, 1999 2:46 AM > To: Doug Rabson > Cc: FreeBSD current Mailing list > Subject: Re: priorities > > On Fri, 21 May 1999, Doug Rabson wrote: > > If you've worked on Windows or Macs, you know what I'm talking about > ("Device failure" or "Could not switch your connection due to an > error"). > [ML] Or my all-time-favorite from Excel: "File was not saved." /Marino To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
RE: swap on Irix (overcommiting, etc.)
> -Original Message- > From: Matthew Dillon [SMTP:dil...@apollo.backplane.com] > Sent: Thursday, April 15, 1999 9:38 PM > To: Mikhail Teterin > Cc: curr...@freebsd.org > Subject: Re: swap on Irix (overcommiting, etc.) > > If some of you are wondering why some of us are saying this > guarenteeing > of memory is a crap argument, it's because it *IS* a crap > argument. > [ML] hey, I know it's a crap argument, that's why I did not raise any objections concerning memory overcommit (even though I am the one who has read the STDC document in an anal-retentive manner regarding malloc failures). One simply has to allocate sufficient swap so that the processes do not get killed before the machine swaps itself to death :) In my experience, this is about 5xRAM for a smallish desktop, 1xRAM for a database server (but do not let any badly behaved programs run on the latter machine). There is a "feature" of HPUX (and I think SINIX and Solaris as well) that they are capable of potentially swapping into a mounted filesystem. The actual filesystem swapping is very slow, and is used by the system as the last resort only--merely, swap is "reserved" there (reserved in the sense that the systems idea of free space in the filesystem is reduced by (a fraction of) the reserved amount i.e. the system keeps statistics about how much VM would have been needed if no overcommit were used, how much of the swap was really used, and how much of the filesystem swap was actually used). If the sysadmin ever sees non-zero actual filesystem swap usage, he better increases RAM/swap. Alas, I do not quite know whether this "feature" were possible in FreeBSD, or how hard would it be to implement it. It does not really solve anything, but it brings you somewhat further along. OTOH, just normal swap monitoring on FreeBSD provides you with the same information, and is practically as safe (okay, the filesystem swappers have an emergency swap area as well, which means that they can err on the low side with actual swap, but this doesn't really bring anything.) /Marino (who really did not expect this thread will explode so :) > -Matt > Matthew Dillon > > > > > 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
RE: swap-related problems
> -Original Message- > From: Mikhail Teterin [SMTP:m...@kot.ne.mediaone.net] > Sent: Wednesday, April 14, 1999 5:01 PM > To: curr...@freebsd.org > Subject: Re: swap-related problems > > They then, rightfully exclaimed: > > . but should not malloc() have returned me NULL? > > And the rest is drowned in the explanations of why it is very hard to > assure. > I'm repeating myself here and so do others. We are probably facing the > major > disadvantange of the "overcommit" strategy, and there may not, indeed, > be a > way around this. > [ML] Short of disabling memory overcommit, no there is no answer. If you do disable overcommit, prepare to add humongous swap areas (or maybe not--some unices reserve the pages in the filesystem, stealing the free blocks, so to say, but write the dirty pages to the swap partitions. They also keep 2 counters: swap pages reserved, and swap pages actually used. They are capable of swapping into a filesystem should the need actually arise, but are very inefficient in doing so. However, having both numbers--swap reserved and swap used--allows the sysadmin to properly size the swap partitions). > Documenting this properly is what is definitely in order... > [ML] I would agree to this. Perhaps in the IMPLEMENTATION section of the corresponding manpages (malloc, s/brk, fork.) > While we are at this, what is the right way to find out if the > returned pointer > can be used? > [ML] Sadly, in the memory overcommit situation, there is no way to know whether a pointer returned by malloc will cause a process demise or not. The pointer is valid, but the swap area mapping is defered until the page is dirtied (basically, the pointer points to a readonly zero filled physical page and on write the trap handler tries to allocate a backing swap area for the page. If the swap is exhausted, the handler eventually fails. What the system does at this time is irrelevant. Please note that memory overcommit architectures are a rather common optimization; FreeBSD is one of them. They do, however, break the ISO/ANSI C conformance (strictly speaking). /Marino > -mi > > > 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
RE: swap-related problems
> -Original Message- > From: Daniel C. Sobral [SMTP:d...@newsguy.com] > Sent: Wednesday, April 14, 1999 3:04 PM > To: Ladavac Marino > Cc: 'm...@aldan.algebra.com'; curr...@freebsd.org > Subject: Re: swap-related problems > > Ladavac Marino wrote: > > > > Another strategy is to reserve the swap space as soon as it > is > > allocated by the program. This strategy is much more conservative > and > > inherently safer, but it needs much more space: for instance, if you > > have a program with WSS of a gigabyte and you want to system( "date" > ), > > you will need at least 2 gigs of swap because system() does fork() > first > > which means that you get 2 copies of your big program and the system > > cannot know that in one of the copies an exec() will be shortly > > forthcoming--thus, it has to reserve the full WSS for the copy > because > > it will potentially write to all pages of its WSS. > > > > It would be nice if memory overcommit were configurable > (on-off, > > or per process). > > On AIX, you can have it set as a global option and on/off per > process. In my experience, though, setting it to off never solved > anything: if you need memory, you have to add memory. > [ML] Oh, memory overcommit does have its applications. Remember the olden days of FORTRAN when "dynamic memory allocation" was a meaningless term :) Overcommit let the people "allocate" a 1*1 matrix and use only a 20*20 subset of it and have program execute instead of fail out-of-swap. Nowadays, vfork() could solve most of the problems on fork/exec. Sadly, a frightening number of unices "implement" vfork() as #define vfork fork /Marino > -- > Daniel C. Sobral (8-DCS) > d...@newsguy.com > d...@freebsd.org > > "nothing better than the ability to perform cunning linguistics" > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
RE: swap-related problems
> -Original Message- > From: Mikhail Teterin [SMTP:m...@misha.cisco.com] > Sent: Wednesday, April 14, 1999 12:45 AM > To: curr...@freebsd.org > Subject: Re: swap-related problems > > > Well, this is just an implementation detail, is not it? I don't > mean to critisize, or anything, but such thing as "no available > memory" is a fairly intuitive... Coming down, again, the malloc > should return a usable memory if available and NULL if it's not. > Is not this a "natural" semantics? Why can a program die because > _another_ program ate up all the rest of the memory? > > [ML] This is a common problem for any OS that implements memory overcommit. This means that it is not possible to detect an out-of-swap condition sinchronously as the swap is reserved only when the pages are dirtied and not when brk is grown. This means that you can set brk a gigabyte higher (given that your user limits allow that), and you will not be using swap as long as you do not write to the pages you "allocated" to the process. Another strategy is to reserve the swap space as soon as it is allocated by the program. This strategy is much more conservative and inherently safer, but it needs much more space: for instance, if you have a program with WSS of a gigabyte and you want to system( "date" ), you will need at least 2 gigs of swap because system() does fork() first which means that you get 2 copies of your big program and the system cannot know that in one of the copies an exec() will be shortly forthcoming--thus, it has to reserve the full WSS for the copy because it will potentially write to all pages of its WSS. It would be nice if memory overcommit were configurable (on-off, or per process). /Marino To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
RE: DoS from local users (fwd)
> -Original Message- > From: Amancio Hasty [SMTP:ha...@rah.star-gate.com] > Sent: Sunday, April 11, 1999 5:36 AM > To: Matthew Dillon > Cc: Dmitry Valdov; Brian Feldman; freebsd-current@FreeBSD.ORG > Subject: Re: DoS from local users (fwd) > > > > I guess any sufficiently advance science is indeed consider magic by > some. > > Amancio > [ML] Then I would like to have a high-tech gizmo for reading my users' minds. Would you, perhaps, know where I could buy/borrow/steal one of these? :) /Marino To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
RE: Games
> -Original Message- > From: Daniel C. Sobral [SMTP:d...@newsguy.com] > Sent: Thursday, April 01, 1999 1:14 PM > To: Alexander Leidinger > Cc: curr...@freebsd.org; tr49...@rcc.on.ca > Subject: Re: Games > > Alexander Leidinger wrote: > > > > On 1 Apr, Daniel C. Sobral wrote: > > > > > Well, first of all, .profile, .cshrc and signature scripts are > > > broken in the absense of fortune. > > > > If I remember correctly .cshrc contains > > [ -x /usr/games/fortune ] && ... > > so this shouldn't be an issue. > > Well, some people seem to be able to survive without fortune, but > that's probably the exception to the rule... :-) > [ML] Oh, I can live without fortune(6), but pom(6) was invaluable in software malfunction diagnosis: luser: "My program fails when I do this or that." me: "No wonder, the moon is 73% full." /Marino > -- > Daniel C. Sobral (8-DCS) > d...@newsguy.com > d...@freebsd.org > > "nothing better than the ability to perform cunning linguistics" > > > > 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
RE:
> -Original Message- > From: Sheldon Hearn [SMTP:sheld...@iafrica.com] > Sent: Tuesday, March 30, 1999 3:47 PM > To: ca...@avias.com > Cc: freebsd-current@freebsd.org > Subject: Re: > > > > On Tue, 30 Mar 1999 17:28:06 +0400, Ilya Naumov wrote: > > > i wonder what is the situation with AIC driver now? we're suffering > > without it :) > > All traces of it have been completely removed from CURRENT. > [ML] Hey, not all is lost. You can still use your 1510 as an el-cheapo external SCSI case connector. What I did after my ancient 386SX-16 died was to throw away the motherboard and use the case as a 5-bay case (it was a midi-tower). The 1510 came in handy because it was cheaper than the ribbon-to-50-pin-D SCSI adapter. Of course I did not bother to power the card :) /Marino To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
RE: UPDATE4: ATA/ATAPI driver new version available.
> -Original Message- > From: Soren Schmidt [SMTP:s...@freebsd.dk] > Sent: Tuesday, March 30, 1999 1:29 PM > To: sobo...@altavista.net > Cc: curr...@freebsd.org > Subject: Re: UPDATE4: ATA/ATAPI driver new version available. > > It seems Maxim Sobolev wrote: > > > >New ata driver (cvsup'ed several minutes ago) locks my box solid > (only > >reset but ton can help). Bug is fully reproducible on my machine > (Toshiba Satellite Pro 445). > >I using the following command: dd if=/dev/zero of=/dev/ad0s2 > bs=1024k. It > >works several minutes then IDE led turns off and box freezes. > Interesting that > >when I looking at systat -vm measures, performance constantly > degrades from > >3.3MB/s to 2.5MB/s. > >Bug exist either in single-user and in multi-user mode. Following is > relevant dmesg pieces from my dmesg output: > > Hmm, are you sure you want to WRITE all those zeros to your disk ?? > However it should not hang before the end of disk is reached that is. > Have you tried reading all of the disk instead, does that hang ?? > The degradation is probably becuse the transferrate of the disk slows > down as you get closer to the center of the disk. > Have you anu idea on how much data is transferred ?? how long is it > running ?? [ML] Also, is there any swapping area on that slice? Because if there is and kernel has been told to use it (AFAIR swapon happens even in single user mode) you have just obliterated the kernel pages (kernel is pageable these days IIRC, at least the data if not the code). /Marino > -Søren > > > 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
RE: repeated ufs_dirbad() panics on 4.0-c
> -Original Message- > From: Ollivier Robert [SMTP:robe...@keltia.freenix.fr] > Sent: Thursday, March 18, 1999 12:26 AM > To: curr...@freebsd.org > Subject: Re: repeated ufs_dirbad() panics on 4.0-c > > According to Mikhail A. Sokolov: > > nope > > > > /dev/da1e17235735 7414244 844263347%/mnt/arc > > /dev/da2e 8617355 1724705 689265020% > /mnt/spool1 > > /dev/da3e 8617355 1723638 689371720% > /mnt/spool2 > > disklabel output is what you want to send us, df is not enough :-) > [ML] In his case it is, because if you take a very careful look, you will see that he's using the e compatibility partition on three separate disks :) So, it's probably not overlapping, but the compatibility that may cause problems. /Marino To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
RE: disk quota overriding
> -Original Message- > From: Dmitry Valdov [SMTP:d...@dv.ru] > Sent: Wednesday, March 17, 1999 1:37 PM > To: freebsd-current@freebsd.org; freebsd-secur...@freebsd.org > Subject: Re: disk quota overriding > > Hi! > > > I think that there is only one way to fix it - it's to disable making > *hard*links to directory with mode 1777. > [ML] But only if the quotas have been turned on. BTW, has chown been "fixed" to the ludicrous SysV semantics that the root and owner can chown a file? If so, the latter has to be disabled in presence of quotas on the volume--otherwise: touch big_file chmod 777 big_file chown root:wheel big_file cat /dev/zero >>big_file This joke used to work on HPUX 10.something which kept the owner-may-chown semantics even in presence of quotas. It was not funny. (I don't know whether HP has fixed that). /Marino To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
RE: Simple DOS against 3.x locks box solid
> -Original Message- > From: Peter Jeremy [SMTP:peter.jer...@auss2.alcatel.com.au] > Sent: Friday, March 05, 1999 4:25 AM > To: dil...@apollo.backplane.com > Cc: curr...@freebsd.org > Subject: Re: Simple DOS against 3.x locks box solid > > > As for the general problem, is it sensible to allow a read-only file > to > be mmap'd R/W (with or without MAP_PRIVATE) and then written into? It > would be fairly easy to make mmap() return EACCES if the fd was not > open for writing (or map the memory R/O and SEGV on a write). [ML] Can you say dlopen( "/usr/lib/libc.so")? I thought you could :) Disallow RW MAP_PRIVATE maps of RO files and shared libraries are history. /Marino > Peter > > > 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
RE: ATAPI and ATAPI_STATIC with the new ATA* driver?
> -Original Message- > From: Sheldon Hearn [SMTP:sheld...@iafrica.com] > Sent: Wednesday, March 03, 1999 1:40 PM > To: Cejka Rudolf > Cc: freebsd-current@freebsd.org; s...@freebsd.dk > Subject: Re: ATAPI and ATAPI_STATIC with the new ATA* driver? > I'm not sure I understand what real-world frustrations people are > having > here. Is this thread the product of reactionary criticism, or are > there > real examples of situations in which there are serious disadvantages > to > the way Soren has things working? > [ML] Well, it's for those people who plug a drive occasionally into a computer. They don't want other drives moved around. This is the situation that the external SCSI disc case owners live with for years now, and was the reason device wiring was introduced for SCSI devices. Soeren said that the same mechanism could be added for atapi devices as well (yet better, extended to include the atapi devices as well). He just doesn't currently have time to do it right now. /Marino > Ciao, > Sheldon. > > > 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
RE: IDE CDROM not found with PIIX4 chipset, -current kernel
> -Original Message- > From: Sheldon Hearn [SMTP:sheld...@iafrica.com] > Sent: Thursday, February 25, 1999 5:40 PM > To: Pierre Beyssac > Cc: Greg Lehey; freebsd-current@FreeBSD.ORG > Subject: Re: IDE CDROM not found with PIIX4 chipset, -current > kernel > > > > On Thu, 25 Feb 1999 17:16:53 +0100, Pierre Beyssac wrote: > > > I tried to find out why it worked with a Linux kernel by comparing > > our IDE code and theirs, but it was way beyond my comprehension. > > I'm not trained for the black magic of IDE probing. > > I used this particular issue for the launch of my first adventure into > serial console kernel debugging. Multo fun. > > I can offer you two interesting points: > > 1) I have an ATAPI drive that FreeBSD 2.2-STABLE won't detect on boot > if >it contains a disc. > > 2) I found that stepping through the kernel caused exactly the same >problems I was having with accessing my one ATAPI drive that I >experience just running normally with my other drive. So it looks >like at least one problem regarding ATAPI has to do with timings. > > So far, the conversations I've had with clueful FreeBSD hackers have > led > me to accept the following: > > A) The ATAPI standard is weak and the variety of implimentations > thereof >is even worse. > > B) The odds that your ATAPI CDROM drive will behave predictably in >accordance with said standards are directly proportional to its > age. >It seems that newer (24xspeed+) drives suck. > > C) The ATAPI code in FreeBSD is about as good as our hackers care to >make it, given the demotivating impact of A and B above. > > I spent a good few days stepping around my kernel over serial > connection, using a "working" 4xspeed drive and a "broken" 36xspeed > drive and testing a reproducible fault with cdcontrol. I'm a pretty > stubborn guy, but I gave up. [ML] Heh, it would seem that the prevailing OS is not really ATAPI compliant and the manufacturers try to make their hardware more easily detectable for the prevailing OS family. How about this "brilliant" idea: put a logic analyzer on the IDE cable and measure the timings the prevailing OS family/BIOS uses? Sadly, I don't have access to a logic analyzer :( Anyone with (good) connections to a (university) hardware lab? /Marino > Ciao, > Sheldon. > > > 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
RE: Need Help
> HI > > I have a trouble with FreeBSD 2.1.5 [ML] 2.1.5 is hardly current (it used to be, some years ago :) > After a mistyped rm :( when i try some commands like ps or netstat i > got > this message: [ML] Careful with those thumbs when you run as root :) > ps: /dev/drum: No such file or directory [ML] An obsolete device (would have to take a look at 2.1.5 sources to be able to tell you what it was. IIRC, it used to be swap in Version7 days) > What does it mean ? [ML] That means that most probably all your device nodes are gone, and that you should cd /dev ./MAKEDEV in order to try to recreate them. Beware, most probably this will not help very much because who knows what else did you delete -- was it perchance a rm -rf * in / ? > How can i fix it? [ML] Reinstall is really your only option. Followed by the restore so that you get back all the user files. You do make backups, don't you? > The system still run .. for the moment..(sob). [ML] But will probably fail to reboot. It might manage to mount /, but the other partitions are most probably unreachable. > Please Help!! [ML] Don't run as root. And be very careful when you do. [ML] /Marino > 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
RE: locale errors
> -Original Message- > From: D. Rock [SMTP:r...@cs.uni-sb.de] > Sent: Thursday, February 04, 1999 10:36 AM > To: Joerg Wunsch > Cc: Andrey A. Chernov; curr...@freebsd.org > Subject: Re: locale errors > > > It is impossible. The collate couldn't detect concatenated words, > which sould sort the usual way: > > aussetzen > austreiben > > (just a simple example) > [ML] Shouldn't ß (scharfes-s, sz) be collated as SZ which it really is? /Marino > I noticed the difference while looking into the /R/dist/src directory > during > a "make release". ssys.XX was sorted behind susrbin.XX in ls output. > > I suggest just backing out the stuff with multi character locale > settings > because it is bogus. We should just use the simple phonebook sorting, > because > it is easier to implement, and the people are more familiar with it. > > Duden isn't always right (very true since last year for some parts in > northern Germany) > > Daniel > > P.S. Solaris does sorting the easy way (at least for > LC_COLLATE=de.ISO8859-15 > and LC_COLLATE=de) > > 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
RE: btokup().. patch to STYLE(9) (fwd)
> -Original Message- > From: Mikhail Teterin [SMTP:m...@misha.cisco.com] > Sent: Monday, February 01, 1999 9:41 PM > To: curr...@freebsd.org > Subject: Re: btokup().. patch to STYLE(9) (fwd) > > =Whilst the official codebase may be under the control of a select > =group of committers, the code should be capable of being understood > by > =anyone who is reasonably proficient with C. > > Depends on your definition of "reasonably", Mr. Special Counselor... [ML] I see no cause for name calling. A "Reasonably Proficient" programmer is the one who writes correct code. The one who writes maintainable correct code is "Very Proficient". The one who writes well-documented maintainable correct code is a target for a marriage proposal :) Sadly, few proficient programmers program exclusively in C/C++. Most of us have bills to pay and switch on a drop of a hat from C to PL/I to COBOL to VisualBASIC to Perl to FORTRAN to YouNameIt to ... And, guess what, none of these languages have the same operator precedence as C/C++. But they all have parentheses. Knowledge of operator precedence as a metric of programming proficience--ludicrous. My brain would turn to pretzel if I had to know all the precedence rules in all the languages that I daily have to use. So, yes, I do use parentheses relying on assocciativity only around addition/multiplication. Logical expressions are handled differently in every language--some of them do not even have short-circuiting logical operators--thus, they will be parenthesized. An example that was being thrown around would look like this in my code: /* the reason for branching */ if ( (a * b - c * d) < (e / f) ) { true_part(); } else { false_part(); more_false_part(); } You will have noticed that I put braces around single statements. This has no performance penalty--a reasonable compiler will not create a stack frame--and helps in maintenance. /* copy null-terminated b to a */ for (pa = a, pb = b; (*pa = *pb) != 0; ++pa, ++pb) { /* NOTHING */ } Same thing here--okay, so it is a bit more verbose than absolutely neccessary. The advantage is that the people who are not absolutely acquainted with the syntactical finesse of the language *can* read it and can actually *modify* it without undue hassle. > That's what is being tirelessly debated for the last several days. > [ML] Hopefully we will come to agreement about a reasonable metric for programmer proficiency (and when I am at that, I can also hope for a jackpot in lottery :) /Marino > -mi > > 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
RE: btokup().. patch to STYLE(9) (fwd)
> -Original Message- > From: John Saunders [SMTP:john.saund...@nlc.net.au] > Sent: Monday, February 01, 1999 10:53 AM > To: freebsd-current@FreeBSD.ORG > Cc: Dan Swartzendruber > Subject: Re: btokup().. patch to STYLE(9) (fwd) > > In nlc.lists.freebsd-current you wrote: > > At 12:09 PM 2/1/99 +1100, Gregory Bond wrote: > >>> "You are not supposed to understand this." > > "You are not expected to understand this." > > > It's inside the swtch() function call. Just having a quick look now. > > Inside expand(), where core is allocated for a process, if no core is > available the process is swapped out with a call to xswap(), then > switched out with a call to swtch(). When core becomes available and > the process image is read in from swap, the process will be selected > by swtch() to become runnable. However with the current context, > swtch() > would return and the tail end of the expand() function would execute. > So inside expand() a call is made to save the stack state so that when > swtch() restores this state, the return skips over the expand() > function > entirely. > [ML] I don't understand that. But, then again, I am not supposed to :) P.S I did understand it, but it was too good an opportunitiy to miss. /Marino To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message