Re: SCSI disk naming problem
On Fri, 1 Oct 1999 [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: [snip] That's an interesting argument on the part of a few people. The commercial UNIX I first adminned had wired down, short names for disks (rz0, rz1, rz2, ... ). This was very nice. This one does not resolve the controller problem either as [EMAIL PROTECTED] said. So, I guess dac0t0, dac0t1, ... dac3t4, will be good enough if we want to be short, but anything shorter than this will be meaningless. As long as you don't move a hard disk from one bus on the controller to the other 8-) -Jin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SCSI disk naming problem
On Fri, 1 Oct 1999, Bruce A. Mah wrote: If memory serves me right, [EMAIL PROTECTED] wrote: This one does not resolve the controller problem either as [EMAIL PROTECTED] said. So, I guess dac0t0, dac0t1, ... dac3t4, will be good enough if we want to be short, but anything shorter than this will be meaningless. Well...I personally prefer the short names. On systems with multiple controllers, the commercial UNIX I used (Ultrix) just continued its numbering with rz0, rz1, rz2, ..., rz6, rz7, rz8, ... FreeBSD lets you do exactly the same thing. Having long device names is confusing to users who only have one disk controller (and I'd bet this is the vast majority). It took me a long The vast majority has just one disk. Given the fast growth in disk sizes, that majority will not decrease. time to grok the syntax of Solaris device names and I still get confused about this. Commercial or free doesn't have anything to do with this issue...this scheme would force users to remember and type extra characters that many of them don't need. (/dev/da0s1a is long enough, but /dev/dac0t0d0s1a is a little ridiculous for someone that has only one controller and one drive.) If you want to *SOLVE* the problem, then make the disk wiring happen before the kernel is booted. After all, we have a real cute boot loader that can definately load the /boot/disk.wire file 8-) The problem after all is *NOT* one of names but that disks not change names unless the administrator wishes so. It doesn't matter the least how we call them. [snip] Cheers, Bruce. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Huge Binaries..
On Fri, Oct 01, 1999 at 10:09:31PM +0200, Ollivier Robert wrote: [...] Yes but with the navigator, you can't even mail a link or a page... With Netscape's mail and news sdk you can use your favorite mail and news clients transparently from navigator (like mailto:, news:, or mail page, etc.). The sdk consists of some C headers, docs and a small example. You simply build a small shared library that is loaded by navigator. The shared library uses hooks in navigator and you may perform any action you like (start /usr/bin/mail, mutt, emacs, ...). Björn -- -BEGIN GEEK CODE BLOCK- GCS d--(+) s++: a- C+++(-) UBOSI$ P+++(-) L+++(--) !E W- N+ o+ K- !w !O !M !V PS++ PE- PGP++ t+++ !5 X++ tv- b+++ D++ G e+ h-- y+ --END GEEK CODE BLOCK-- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Huge Binaries..
On Sat, Oct 02, 1999 at 12:15:09PM +0200, Bjoern Fischer wrote: On Fri, Oct 01, 1999 at 10:09:31PM +0200, Ollivier Robert wrote: [...] Yes but with the navigator, you can't even mail a link or a page... With Netscape's mail and news sdk you can use your favorite mail and news clients transparently from navigator (like mailto:, news:, or mail page, etc.). The sdk consists of some C headers, docs and a small example. You simply build a small shared library that is loaded by navigator. The shared library uses hooks in navigator and you may perform any action you like (start /usr/bin/mail, mutt, emacs, ...). Do you know anything about their Enterprise Calendar server support that they've introduced in 4.7? Is this their own protocol, or is it something fairly standard under the bonnet? Joe -- Josef KarthauserFreeBSD: 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-hackers" in the body of the message
Re: Huge Binaries..
According to Bjoern Fischer: The sdk consists of some C headers, docs and a small example. You simply build a small shared library that is loaded by navigator. The shared library uses hooks in navigator and you may perform any action you like (start /usr/bin/mail, mutt, emacs, ...). Wow! I didn't know that. I'll have a look. Anyone has already done the work of running Mutt from Netscape ? :-) -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] FreeBSD keltia.freenix.fr 4.0-CURRENT #74: Thu Sep 9 00:20:51 CEST 1999 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 2.88Mb floppies
Wilko Bulte wrote in list.freebsd-hackers:
As Oliver Fromme wrote ...
I once programmed low-level FDC stuff under DOS, so I'm a bit
familiar with this... The difference between 1.44 and 2.88 Mb
floppies is that the latter use 36 sectors per track and twice
the data rate (1 MBit/s). So the entry should look like this:
{36, 2, 0xff, 0x1b, 80, 5760, 1, FDC_125KBPS, 2, 0x6c, 1}
Actually, there should be a #define FDC_1MBPS FDC_125KBPS
Eh, I guess you mean:
{36, 2, 0xff, 0x1b, 80, 5760, 1, FDC_1MBPS, 2, 0x6c, 1} ?
No, FDC_1MBPS is not defined (that's why I said that it
_should_ be defined).
Actually, FD controllers use a 2bit flag to indicate the
transfer speed, and traditional controllers interpreted those
four values as 125, 250, 300 and 500 kbps. Newer controllers
dumped the 125 kbps support and interpret the same bits as
1000 kbps. So using FDC_125KBPS is OK.
Beware, I have not actually tried this with FreeBSD, and there
might be bugs that prevent using 2.88 Mb floppies.
Regards
Oliver
--
Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany
(Info: finger userinfo:[EMAIL PROTECTED])
"In jedem Stück Kohle wartet ein Diamant auf seine Geburt"
(Terry Pratchett)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: SCSI disk naming problem
On Sat, Oct 02, 1999 at 01:15:53PM +0300, Narvi wrote: On Fri, 1 Oct 1999 [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: [snip] That's an interesting argument on the part of a few people. The commercial UNIX I first adminned had wired down, short names for disks (rz0, rz1, rz2, ... ). This was very nice. This one does not resolve the controller problem either as [EMAIL PROTECTED] said. So, I guess dac0t0, dac0t1, ... dac3t4, will be good enough if we want to be short, but anything shorter than this will be meaningless. As long as you don't move a hard disk from one bus on the controller to the other 8-) Yes something like dac0t0... is realy nice - but AFAIK it's not general enough for fibre channel. The main point is that I only see this problem with removeable disks and other kind of SCSI-devices, which I usually wire down. Most of my fixed disks are running with vinum. vinum is able to handle if a drive has changed it's ID and/or name. It's an important thing to have something like this if you want to be able to hotplug a drive (or power up later). Sometimes it's getting another name than it would have after reboot! -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
umount(8) or unmount(2) ?
Hi,
Since about 5 weeks I'm working on sanity checks and bug fixes
for umount(8), mount(8) and mount_xxx(8). Poul Henning told
me to mail to cvs-committers too, cause many clued people read it.
You'll find my patch and the readme for it on :
http://www.attic.ch/patches/MOUNTPATCH-CURRENT-02101999-01
http://www.attic.ch/patches/MOUNTPATCH-README
My problem is, that all fixes do their work. But it is not clear,
if some work should be in kernel- or user-land. Some people just like to
have umount(8) as a wrapper to unmount(2) and don't like umount(8)
to do sanity checks. This is the case for this part of umount(8) I've
replaced:
- origname = name;
- if (stat(name, sb) 0) {
- mntpt = rname;
- if ((getmntname(rname, MNTFROM, type) == NULL)
- ((mntpt = getmntname(name, MNTON, type)) == NULL)) {
- warnx("%s: not currently mounted", name);
- return (1);
- }
I've replaced stat() and realpath() on the mountpoint with () realpath on
the basedir of the mointpoint and added some sanity checks. Most of my
mount-order checks I added in umount(8) relay on a resolved mountpoint.
I've implemented this as an idea from phk and it works very well. If we
unmount a hanged nfs-mount - it hangs no in kernel (if busy), not in
userland. This is a little step forward. Some side-effects of this
part of my patch are, that some other PR's are fixed too :
o [1999/02/03] bin/9893 NFS umount of regular file impossible
s [1995/11/27] bin/841 stale nfs mounts cannot be umounted
If we find the mntonname or mntfromname in the mounttable, we just
go ahead and unmount it. No stat() or anything else is needed.
Please tell me what you're thinking about these ideas and the work I've
done and show me why I am wrong. Thank you very much !
Martin
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: 2.88Mb floppies
As Oliver Fromme wrote ...
Wilko Bulte wrote in list.freebsd-hackers:
As Oliver Fromme wrote ...
I once programmed low-level FDC stuff under DOS, so I'm a bit
familiar with this... The difference between 1.44 and 2.88 Mb
floppies is that the latter use 36 sectors per track and twice
the data rate (1 MBit/s). So the entry should look like this:
{36, 2, 0xff, 0x1b, 80, 5760, 1, FDC_125KBPS, 2, 0x6c, 1}
Actually, there should be a #define FDC_1MBPS FDC_125KBPS
Eh, I guess you mean:
{36, 2, 0xff, 0x1b, 80, 5760, 1, FDC_1MBPS, 2, 0x6c, 1} ?
No, FDC_1MBPS is not defined (that's why I said that it
_should_ be defined).
Actually, FD controllers use a 2bit flag to indicate the
transfer speed, and traditional controllers interpreted those
four values as 125, 250, 300 and 500 kbps. Newer controllers
dumped the 125 kbps support and interpret the same bits as
1000 kbps. So using FDC_125KBPS is OK.
Ah.. talking about confusing. It's been a long time since I
had to design a FDC on a SCSI adapter card. Project got scrapped too :-(
Beware, I have not actually tried this with FreeBSD, and there
might be bugs that prevent using 2.88 Mb floppies.
I hope to give it a quick try next week.
--
| / o / / _ Arnhem, The Netherlands- Powered by FreeBSD -
|/|/ / / /( (_) BulteWWW : http://www.tcja.nl http://www.freebsd.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Cosmetic changes to whois(1)
I've just made two very minor (cosmetic) modifications to whois(1): 1. Added -m option, which selects whois.ra.net as the whois server. This server publishes routing policy for a large number of network operators, and is currently run by Merit (see www.ra.net for more details). 2. Added -q option, which constructs a whois server to use based on the TLD of the (single) argument, with ".whois-servers.net" appended. The whois-servers.net zone is run by the people at ultradns.com. This allows, for example, queries like whois -q patho.gen.nz whois -q microsoft.com whois -q nasa.gov whois -q nic.fr whois -q demon.co.uk to all provide meaningful output without having to worry about different whois switches for different registries. Small, simple patch included in bin/14095. Comments welcome :) Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
No Subject
Bcc: Subject: Re: FTP directory listing with ftpio(3) and fetch(3) Reply-To: In-Reply-To: [EMAIL PROTECTED] Dag-Erling Smorgrav wrote: Type 'man 3 fetch', scroll down to the BUGS section, and see the light. Next, scroll back up to the AUTHORS section and find out who to contact :) (fetch stuff) BTW.. although risking to be off-topic by miles, I always liked the way how NetBSD's ftp(1) (since 1.4 or so) implemented http and ftp URL fetching and thus eliminated the need for a fetch(1) command. Couldn't the FreeBSD ftp(1) be enhanced that way, [ObTopic, slime slime] to use fetch(3) for that purpose? (Or just "steal" the NetBSD implementation, FreeBSD aren't the Knights who say NIH, I would hope.) I'd really love to have yet another superfluous userland tool like fetch(1) go away, especially because it collides in namespace with another fetch program and the functionality could be very well integrated with the ftp utility. Personally, I find fetch(1) a bad idea. Cc'ied to -questions, for obvious reasons, thanks for your attention :). mkb To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: your mail
On Sun 1999-10-03 (07:22), Matthias Buelow wrote: Bcc: Subject: Re: FTP directory listing with ftpio(3) and fetch(3) Reply-To: In-Reply-To: [EMAIL PROTECTED] BTW.. although risking to be off-topic by miles, I always liked the way how NetBSD's ftp(1) (since 1.4 or so) implemented http and ftp URL fetching and thus eliminated the need for a fetch(1) command. Couldn't the FreeBSD ftp(1) be enhanced that way, [ObTopic, slime slime] to use fetch(3) for that purpose? This is where a useful tool like wget comes into play. Wget can be pretty much used as an automated replacement for fetch, or FTP URL retrieval. Can also be plugged into the whole ports system so that it can retrieve the ports data packages. I'd really love to have yet another superfluous userland tool like fetch(1) go away, especially because it collides in namespace with another fetch program and the functionality could be very well integrated with the ftp utility. Personally, I find fetch(1) a bad idea. root@rucus:~# ls -lad `which fetch` -r-xr-xr-x 1 root wheel 35300 Jun 11 22:10 /usr/bin/fetch root@rucus:~# ls -lad `which wget` -r-xr-xr-x 1 root wheel 103240 Dec 23 1998 /usr/local/bin/wget root@rucus:~# ls -lad `which ftp` -r-xr-xr-x 3 root wheel 72312 Jun 11 22:10 /usr/bin/ftp as this shows fetch is a far more leightweight implementation. Important when considering its use in systems like picobsd, or other small projects. The whole *nix philosophy is to have a myrid of tools that all do a job, and the joy/pain, comes in the blending, and linking of these tools together in order to perform a complex task. Barry -- -- Barry Irwin IRC: balin@zanet (#linux) [EMAIL PROTECTED] http://rucus.ru.ac.za/~bvi Whois BI414 - PMPN8EZ - http://moria.org -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
