Re: BSD XFS Port BSD VFS Rewrite
On Sat, Aug 14, 1999 at 12:23:00PM -0400, Brian F. Feldman wrote: On Sat, 14 Aug 1999, James Howard wrote: I heard somewhere that Linux was released under a slightly modified GPL to permit the inclusion of BSD code. I assumed they did this to steal the IP stack. Most likely. Nope. Linux has always had it's own IP stack. That's where the "Linux's network performance is poor" arguments came from. Of course, it's a lot better these days. -- Dom Mitchell -- Palmer Harvey McLane -- Unix Systems Administrator "Finally, when replying to messages only quote the parts of the message your will be discussing or that are relevant. Quoting whole messages and adding two lines at the top is not good etiquette." -- Elias Levy -- ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ** To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [Review please] (was: Re: cvs commit: src/gnu/usr.bin/man/manpath manpath.config)
Ruslan Ermilov [EMAIL PROTECTED] writes: How about the following patch. It adds an OPTIONAL_MANPATH directive, which is equivalent to the MANDATORY_MANPATH, except an absence of the directory is not considered an error. Sure. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Configuration mechanism of PCI bus
On 1999-08-09 22:08 -0400, Zhihui Zhang [EMAIL PROTECTED] wrote:
Even with "PCI System Architecture, 4th edition" at hand, I still have
some problems understanding the code in isa/pcibus.c. Please point out
any misunderstanding I may have in the following:
It has been some time since I write that code, but I'll try to remember
why it became the way you found it ... ;-)
(1) At first, you can not modify the address port at 0xcf8 without a FULL
32-bit write. The routine pci_cfgopen() seems to use this fact.
Yes.
(2) The constant CONF1_ENABLE_MSK includes 4 higher bus number bits, only
4 bits can be used as bus number, so we can have at most 16 PCI buses.
This is partially true. The code assumes (and I have yet to meet a PCI
BIOS that violates that assumption), that the address register will not
have any of the bits masked by 0x7ff0 set. This is generally true,
since the **last** prior access to PCI config space by the BIOS will
have been to a PCI bridge (i.e. to a bus number much lower than the
highest PCI bus number in the system).
You are correct: If the previous config cycle was to a bus higher than 15,
then this heuristic will assume that there is no configuration mechanism 1
address register. I had to add that heuristic in order to prevent the PCI
porbe from crahsing EISA only systems.
(3) The variable "mode1res" seems to refer to any residual left by BIOS in
the address port. If it is non-zero, we will try to find a device using
configuration mechanism 1.
Yes. Writing 0xff00 should result in 0x8000 being read back.
Only the MSB is writable, the remaining high order bits are wired to 0.
This is another test that is most likely to fail for non-PCI systems.
(3) The magic constant 0xf870ff excludes many devices. How it is chosen?
I guess those excluded devices are not important or supported by FreeBSD.
It seems to me that if pci_cfgcheck() finds at least one device, then the
configuration mechanism is regarded as correctly detected.
Yes. After testing for config mechanism 1 or 2, another last test is done
to make sure, there is at least one PCI device on the bus. The mask is
chosen in such a way, that there is at least one device on PCI bus 0, which
satisfies the following conditions:
class in 0..7
subclass in 0..15 or equal 0x80 (in fact 0x80 .. 0x8f are accepted)
prog if equal 0
and finally
class not equal 0 or subclass not equal 0
This will for example be true for a PCI VGA card (present in just about
every system), which has class=0 and subclass=1 or class=3 and subclass
in {0,1,0x80}. But in any PCI 2.0 or later system, the chip-set will also
be present on PCI bus 0 and will cause a match with class=6 and subclass
in 0 .. 7 (or 0x80). Any disk or network controller should also suffice
to make this test succeed.
The only case that will have this test fail is an ancient (pre PCI-2.0)
system with no PCI VGA card.
Regards, STefan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: How do you allocate dma channel with newbus?
Larry Lile wrote: I am feeling a little dense today, how do you allocate a dma channel for a PCI busmaster device with newbus? You don't. PCI busmastering doesn't use dma channels. Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: BSD XFS Port BSD VFS Rewrite
On Fri, 13 Aug 1999, Terry Lambert wrote: Has anyone mentioned to them that they will be unable to incorporate changes made to the GPL'ed version of XFS back into the IRIX version of XFS, without IRIX becoming GPL'ed? Given that they say they're dropping IRIX and going with Linux, I don't think it'll be a problem. Can you please site a reference for this, other than wishful thinking by the Linux camp? PS: I fired off a note to Dr. Forest Baskett at SGI (their senior VP for R D, and their CTO) about the license, and FS researchers in the BSD community (e.g. Dr. Margo Seltzer, Dr. Kirk McKusick, John Heidemann, et. al.) which will be unable to participated in driving their technology forward because of the license. I will report the response (if any). Terry Lambert [EMAIL PROTECTED] --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IDE quirk in 3.2-STABLE kernel ?
Hi folks, I didn't see any pointers other than pilot error raised in the recent thread with subject line: Subject: Re: IDE quirk in 3.2-STABLE kernel ? Perhaps those of you who're in support of the pilot error notion could have a look at PR 13174 and comment? The originator claims that his kernel only finds wdc0 when he "auto-detects" his hard drives with his Award BIOS. He doesn't specify whether he has drives connected to that controller, which is why I've cc'd him on this mail. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: BSD XFS Port BSD VFS Rewrite
On Mon, 16 Aug 1999, Terry Lambert wrote: On Fri, 13 Aug 1999, Terry Lambert wrote: Has anyone mentioned to them that they will be unable to incorporate changes made to the GPL'ed version of XFS back into the IRIX version of XFS, without IRIX becoming GPL'ed? Given that they say they're dropping IRIX and going with Linux, I don't think it'll be a problem. Can you please site a reference for this, other than wishful thinking by the Linux camp? Here's one: http://www.zdnet.com/pcweek/stories/news/0,4153,1015908,00.html But just about every trade rag covered it. Vince. -- == Vince Vielhaber -- KA8CSH email: [EMAIL PROTECTED] flame-mail: /dev/null # include std/disclaimers.h TEAM-OS2 Online Campground Directoryhttp://www.camping-usa.com Online Giftshop Superstorehttp://www.cloudninegifts.com == To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: BSD XFS Port BSD VFS Rewrite
On Fri, 13 Aug 1999, Terry Lambert wrote: Has anyone mentioned to them that they will be unable to incorporate changes made to the GPL'ed version of XFS back into the IRIX version of XFS, without IRIX becoming GPL'ed? Given that they say they're dropping IRIX and going with Linux, I don't think it'll be a problem. Can you please site a reference for this, other than wishful thinking by the Linux camp? Here's one: http://www.zdnet.com/pcweek/stories/news/0,4153,1015908,00.html But just about every trade rag covered it. Begging your pardon, but: | --- With the help of Veritas Software Corp., SGI will work to add | key features of its Irix operating system to the Linux platform. | Currently, Irix runs on the MIPS platform. Once SGI switches | entirely to Intel Corp.'s IA/64 platform, that will be the end of | Irix. | | SGI is also forming an alliance with NEC Corp. to increase its | market share in Japan. These paragraphs are contradictory. It implies an end to MIPS. Nintendo 64 uses MIPS. It also seems a bit overzealous. Terry Lambert [EMAIL PROTECTED] --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: BSD XFS Port BSD VFS Rewrite
On Mon, 16 Aug 1999, Terry Lambert wrote: On Fri, 13 Aug 1999, Terry Lambert wrote: Has anyone mentioned to them that they will be unable to incorporate changes made to the GPL'ed version of XFS back into the IRIX version of XFS, without IRIX becoming GPL'ed? Given that they say they're dropping IRIX and going with Linux, I don't think it'll be a problem. Can you please site a reference for this, other than wishful thinking by the Linux camp? Here's one: http://www.zdnet.com/pcweek/stories/news/0,4153,1015908,00.html But just about every trade rag covered it. Begging your pardon, but: | --- With the help of Veritas Software Corp., SGI will work to add | key features of its Irix operating system to the Linux platform. | Currently, Irix runs on the MIPS platform. Once SGI switches | entirely to Intel Corp.'s IA/64 platform, that will be the end of | Irix. | | SGI is also forming an alliance with NEC Corp. to increase its | market share in Japan. These paragraphs are contradictory. It implies an end to MIPS. Nintendo 64 uses MIPS. It also seems a bit overzealous. No argument here. Perhaps they're just trying to float a few trial baloons in hopes of finding something popular/feasable. Vince. -- == Vince Vielhaber -- KA8CSH email: [EMAIL PROTECTED] flame-mail: /dev/null # include std/disclaimers.h TEAM-OS2 Online Campground Directoryhttp://www.camping-usa.com Online Giftshop Superstorehttp://www.cloudninegifts.com == To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: BSD XFS Port BSD VFS Rewrite
--- Terry Lambert [EMAIL PROTECTED] wrote: On Fri, 13 Aug 1999, Terry Lambert wrote: Can you please site a reference for this, other than wishful thinking by the Linux camp? Here's one: http://www.zdnet.com/pcweek/stories/news/0,4153,1015908,00.html But just about every trade rag covered it. Begging your pardon, but: | --- With the help of Veritas Software Corp., SGI will work to add | key features of its Irix operating system to the Linux platform. | Currently, Irix runs on the MIPS platform. Once SGI switches | entirely to Intel Corp.'s IA/64 platform, that will be the end of | Irix. | | SGI is also forming an alliance with NEC Corp. to increase | its market share in Japan. These paragraphs are contradictory. It implies an end to MIPS. Contradictory how? NEC's a big PC manufacurer in Japan. If SGI is moving toward more conventional off-the-shelf components, they stand to gain tremendously by an alliance, both from manufacturing and distribution standpoints. Nintendo 64 uses MIPS. It also seems a bit overzealous. So do the old and new Playstation models. The MIPS core is being manufactured by several companies: IDT alone has something like a dozen variants available with and without MMU, FP, 5000 vs 1 core, etc. and is in far wider use than in just PCs and gaming consoles. I doubt if SGI machines abandoning MIPS processors would put much of a dent in MIPS' profitability. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: BSD XFS Port BSD VFS Rewrite
I lost track of the quotes. | --- With the help of Veritas Software Corp., SGI will work to add | key features of its Irix operating system to the Linux platform. | Currently, Irix runs on the MIPS platform. Once SGI switches | entirely to Intel Corp.'s IA/64 platform, that will be the end of | Irix. | | SGI is also forming an alliance with NEC Corp. to increase its | market share in Japan. These paragraphs are contradictory. It implies an end to MIPS. an end to irix and an end to MIPS on desktop and server platforms has no big effect on MIPS processors. The big volume for MIPS is embedded, or so I am told. For an interesting take on all this visit www.mipsabi.org ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: IDE quirk in 3.2-STABLE kernel ?
I didn't see any pointers other than pilot error raised in the recent thread with subject line: Subject: Re: IDE quirk in 3.2-STABLE kernel ? Perhaps those of you who're in support of the pilot error notion could have a look at PR 13174 and comment? The originator claims that his kernel only finds wdc0 when he "auto-detects" his hard drives with his Award BIOS. He doesn't specify whether he has drives connected to that controller, which is why I've cc'd him on this mail. I apologize for the missing information. This problem has been posted several times (by me) to the -stable mailing list, and I simply forgot to include all the details with the bug report. The only reason why this would be a critical bug is if there were drives connected to the primary controller. In this case, I only have IDE drives, which means that the kernel cannot mount the root filesystem without wcd0 being detected. I have two drives on wcd0: a 1.27 GB Samsung as master (with root filesystem) and a 6.54 GB Seagate (with /usr, and others). I have an ATAPI CD-ROM drive as master on wcd1 (which is detected just fine). I've noticed this behaviour with every 3.- branch installation I've had on my machine (3.2-RELEASE boot disks, 3.2-STABLE). I have 4 other OSs on the same machine, so I would prefer not to mess with the physical configuration (i.e. moving disks from one controller to another, etc), which would mess up their drive configurations. Please note that this is not a problem with IRQ's, etc. I've had 2.2.8-RELEASE and -STABLE running on the same machine with absolutely no problems detecting wcd0 (and the default IRQ's and port addresses for both 2.2.8 and 3.2 are the same). Any help is appreciated. Andrew J. Lofthouse To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Whither makefiles for src/crypto/telnet/* ?
Date: Sat, 14 Aug 1999 14:35:34 -0700 (PDT)
From: Kris Kennaway [EMAIL PROTECTED]
I also have prototype code which can store multiple password hashes in the
password file, and retrieves "secondaries" in a new field in struct
passwd. You could conceivably set it up to keep a DES password in sync
with the SRP one, and distribute only the DES over NIS. I don't know how
extensible NIS is, but maybe we could hide the other hashes in there as
well for those who understand them.
I'm hardly an "expert" with NIS, but it is actually fairly flexible...
as long as changes imposed are on its own terms. :-)
For example, you can easily create a new NIS "map" (as was done with the
master.passwd.by{name,uid} maps). However, systems that don't know to
look anything up in such a construct will not pay attention to it.
(For example, a Solaris system hasn't a clue that the map
master.passwd.byname exists, much less that it shoudl be used for
anything, so "login" on such a system ignores that map and tries to do
password verification using the passwd.byname map. If the NIS master
server is a FreeBSD box, by default the passwd.byname map merely has "*"
as the encrypted password, while placing the encrypted password in
master.passwd.byname. This is why it's necessary, in such a situation,
to set the "UNSECURE" flag -- that way, the FreeBSD box will place the
encrypted password in passwd.byname, which placates the Solaris box(en).
On a FreeBSD system, there are special checks to see if the process
accessing the master.passwd.by{name,uid} maps has an euid of 0; if so,
the access is permitted; if not, it isn't. But the Solaris box, since
it never knew about the map, certainly doesn't treat it specially, so
though there's no code to access it to make any decisions, J. Random
User is quite able to do (say) a "ypcat -k master.passwd.byname" from
the Solaris box.)
In an (arguably) similar vein, it is possible to use (new) NIS maps to
hold (say) amd maps. (We do this here.) One merely needs to add the
appropriate stanza(s) to the /var/yp/Makefile, and be sure that there is
code in the appropriate places to go look for information in the NIS
maps in question to the /var/yp/Makefile, and be sure that there is
code in the appropriate places to go look for information in the NIS
maps in question.
So you could create new NIS maps to hold nearly any (textual) key/value
pairs you feel like creating. (Unique keys for a given map would make
this easier.)
Whether or not actually using such a mechanism for decision-making is a
Good Idea(tm) is a rather different issue, though (and is likely to be
implementation (among other things) -dependent).
Hope someone finds a bit of this of use,
david
--
David Wolfskill [EMAIL PROTECTED] UNIX System Administrator
voice: (650) 577-7158 pager: (888) 347-0197 FAX: (650) 372-5915
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
RE: IDE quirk in 3.2-STABLE kernel ?
I didn't see any pointers other than pilot error raised in the recent thread with subject line: Subject: Re: IDE quirk in 3.2-STABLE kernel ? Perhaps those of you who're in support of the pilot error notion could have a look at PR 13174 and comment? The originator claims that his kernel only finds wdc0 when he "auto-detects" his hard drives with his Award BIOS. He doesn't specify whether he has drives connected to that controller, which is why I've cc'd him on this mail. NOTE on last e-mail: I mis-typed the device names; should be 'wdc0' and 'wdc1' (instead of 'wcd0' and 'wcd1') I apologize for the missing information. This problem has been posted several times (by me) to the -stable mailing list, and I simply forgot to include all the details with the bug report. The only reason why this would be a critical bug is if there were drives connected to the primary controller. In this case, I only have IDE drives, which means that the kernel cannot mount the root filesystem without wcd0 being detected. I have two drives on wcd0: a 1.27 GB Samsung as master (with root filesystem) and a 6.54 GB Seagate (with /usr, and others). I have an ATAPI CD-ROM drive as master on wcd1 (which is detected just fine). I've noticed this behaviour with every 3.- branch installation I've had on my machine (3.2-RELEASE boot disks, 3.2-STABLE). I have 4 other OSs on the same machine, so I would prefer not to mess with the physical configuration (i.e. moving disks from one controller to another, etc), which would mess up their drive configurations. Please note that this is not a problem with IRQ's, etc. I've had 2.2.8-RELEASE and -STABLE running on the same machine with absolutely no problems detecting wcd0 (and the default IRQ's and port addresses for both 2.2.8 and 3.2 are the same). Any help is appreciated. Andrew J. Lofthouse To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Whither makefiles for src/crypto/telnet/* ?
On Mon, 16 Aug 1999, David Wolfskill wrote: I'm hardly an "expert" with NIS, but it is actually fairly flexible... as long as changes imposed are on its own terms. :-) Thanks for the information. I noticed some rumblings on the srp-dev mailing list about developing NIS support - I don't think anything has come of it yet, but that would be the place to discuss it so we can get some kind of cross-platform compatability. I'll certainly look into that further when I can start working on this again. Kris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: BSD XFS Port BSD VFS Rewrite
I lost track of the quotes.
| --- With the help of Veritas Software Corp., SGI will work to add
| key features of its Irix operating system to the Linux platform.
| Currently, Irix runs on the MIPS platform. Once SGI switches
| entirely to Intel Corp.'s IA/64 platform, that will be the end of
| Irix.
|
| SGI is also forming an alliance with NEC Corp. to increase its
| market share in Japan.
These paragraphs are contradictory. It implies an end to MIPS.
an end to irix and an end to MIPS on desktop and server platforms has no
big effect on MIPS processors. The big volume for MIPS is embedded, or so
I am told.
For an interesting take on all this visit www.mipsabi.org
Uh, that site is dead, as of the end of this month. See the
first link ("announcement").
Terry Lambert
[EMAIL PROTECTED]
---
Any opinions in this posting are my own and not those of my present
or previous employers.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: BSD XFS Port BSD VFS Rewrite
These paragraphs are contradictory. It implies an end to MIPS. Nintendo 64 uses MIPS. It also seems a bit overzealous. No argument here. Perhaps they're just trying to float a few trial baloons in hopes of finding something popular/feasable. That was my take on things, since no source was attributed. Either that, or press zealotry. Terry Lambert [EMAIL PROTECTED] --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: BSD XFS Port BSD VFS Rewrite
On Mon, 16 Aug 1999, Terry Lambert wrote: On Fri, 13 Aug 1999, Terry Lambert wrote: Has anyone mentioned to them that they will be unable to incorporate changes made to the GPL'ed version of XFS back into the IRIX version of XFS, without IRIX becoming GPL'ed? Given that they say they're dropping IRIX and going with Linux, I don't think it'll be a problem. Can you please site a reference for this, other than wishful thinking by the Linux camp? Here's one: http://www.zdnet.com/pcweek/stories/news/0,4153,1015908,00.html But just about every trade rag covered it. Begging your pardon, but: | --- With the help of Veritas Software Corp., SGI will work to add | key features of its Irix operating system to the Linux platform. | Currently, Irix runs on the MIPS platform. Once SGI switches | entirely to Intel Corp.'s IA/64 platform, that will be the end of | Irix. | Why would switch to IA/64 mean end of IRIX? SGI has long planned to switch to IA/64, but with IRIX. If SGI wants to continue building Origins, esp the high CPU count ones, IRIX is to stay for a long time. | SGI is also forming an alliance with NEC Corp. to increase its | market share in Japan. These paragraphs are contradictory. It implies an end to MIPS. An end to high-end MIPS may come ... if Merced, etc. peform well enough. As this is a topic beaten to death on comp.arch, everybody interested should look there. Nintendo 64 uses MIPS. Which doesn't matter all that much. MIPS cpus for nintendo could be made by say MISP, not SGI (and SGI sold/is trying to sell MIPS). It also seems a bit overzealous. You bet. It seems it is to hard foir the journalists to actually read the press releases. Terry Lambert [EMAIL PROTECTED] --- Any opinions in this posting are my own and not those of my present or previous employers. Sander There is no love, no good, no happiness and no future - all these are just illusions. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: BSD XFS Port BSD VFS Rewrite
I don't think that this is an appropriate forum but I will put in my two cents nonetheless. At least as of a couple of years age MIPS was the most widely used embedded processor in the world. Thus, MIPS is in no way dependent on IRIX. Not to mention that Linux runs on MIPS. -Kip On Mon, 16 Aug 1999, Garance A Drosihn wrote: At 4:19 PM + 8/16/99, Terry Lambert wrote: Begging your pardon, but: | --- With the help of Veritas Software Corp., SGI will work to add | key features of its Irix operating system to the Linux platform. | Currently, Irix runs on the MIPS platform. Once SGI switches | entirely to Intel Corp.'s IA/64 platform, that will be the end | of Irix. | | SGI is also forming an alliance with NEC Corp. to increase its | market share in Japan. These paragraphs are contradictory. It implies an end to MIPS. Nintendo 64 uses MIPS. I don't think those paragraphs are all that contradictory. They just imply the end of SGI selling MIPS-based workstations running IRIX. Nintendo can keep using MIPS, and my guess is that Nintendo is not running IRIX on their machines. What is the contradiction? I'm making the assumption here that Nintendo sells more Nintendo 64 games than SGI sells workstations, and thus SGI dropping MIPS for workstations does *-NOT-* imply the end of MIPS. It only implies the end of IRIX. In any case, even if it is contradictory in some sense, there is no question that SGI is *claiming* that they are all buddy-buddy with linux, and thus they are already comfortable with gnu-licensed software. --- Garance Alistair Drosehn = [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Institute To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
illegal ATAPI command in wdc probe?
The VMWare guest OS page for FreeBSD (http://www.vmware.com/support/technotesfreebsd.html) states, --- One caveat with all versions of FreeBSD is that there is a problem probing for the CD-ROM device wdc1; FreeBSD sends an illegal ATAPI command to the IDE controller and ignores the error status reply. This results in approximately a 1 minute delay each time the system boots. --- Is this true? Charles To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How do you allocate dma channel with newbus?
On Sun, 15 Aug 1999, Larry Lile wrote: I am feeling a little dense today, how do you allocate a dma channel for a PCI busmaster device with newbus? I don't think PCI devices use the ISA DMA controller. "It just works." (EISA has this advantage too.) -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
kernel symbol `gd_curpcb' not found
I have tried to debug a kernel by simulating a panic without success. I have read the handbook and searched the mailinglist. I even tried not to strip the debug kernel at all. Still I get the above message and I do not know how to go on. The following are the commands that I used: now5# gdb -k GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. .. This GDB was configured as "i386-unknown-freebsd". (kgdb) symbol-file /kernel Reading symbols from /kernel...done. (kgdb) exec-file kernel.6 (kgdb) core-file vmcore.6 IdlePTD 3600384 kernel symbol `gd_curpcb' not found. (kgdb) where No stack. Thanks for any help. -- Zhihui Zhang. Please visit http://www.freebsd.org -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Filesystem question...
Actually, i'd expect far fewer problems for the private mounts than for user mounts which modify the name space for all processes ... The concept of private namespaces does not exist on FreeBSD. It would require a modification of the lookup mechanism, and, potentially, a seperation of credentials from the process into a session manager. This is actually the problem at issue in an SMBFS implementation, and for which the Linux guys punted: the credential in SMB is per connection, not per user. There is some newer stuff in LANMan to deal with this inter-NT, and SAMBA incorporates this, but session ID's are not supported over a single VC by all LANMan servers. NetWare has the same problem, FWIW, as does NUC (a client FS for NetWare). Terry Lambert [EMAIL PROTECTED] --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Whither makefiles for src/crypto/telnet/* ?
Cool, another non-exportable system available to US users only. :-) Yeah... isn't it time you Yanks got together and stormed that Trade Dept? I mean, if you can get excited over a few wooden crates containing tea... ;-) ;-) Pound for pound (no pun intended), Tea was much more expensive than gold at the time. That's why all real antique tea cozy's have functional locks. Terry Lambert [EMAIL PROTECTED] --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: BSD XFS Port BSD VFS Rewrite
On Sat, 14 Aug 1999, Terry Lambert wrote: I am currently conducting a thorough study of the VFS subsystem in preparation for an all-out effort to port SGI's XFS filesystem to FreeBSD 4.x at such time as SGI gives up the code. Matt Dillon has written in hackers- that the VFS subsystem is presently not well understood by any of the active kernel code contributers and that it will be rewritten later this year. This is obviously of great concern to me in this port. It is of great concern to me that a rewrite, apparently because of non-understanding, is taking place at all. That concerns me too. Many aspects of the 4.4 vnode interface were there for specific reasons. Even if they were hack solutions, to re-write them because of a lack of understanding is dangerous as the new code will likely run into the same problems as before. :-) Also, it behooves all the *BSD's to not get too divergent. Sharing code between us all helps all. Given that I'm working on the kernel side of a data migration file system using NetBSD, I can assure you there are things which FreeBSD would get access to more easily the more-similar the two VFS interface are. :-) I would suggest that anyone planning on this rewrite should talk, in depth, with John Heidemann prior to engaging in such activity. John is very approachable, and is a deep thinker. Any rewrite that does not meet his original design goals for his stacking architecture is, I think, a Very Bad Idea(tm). I greatly appreciate all assistance in answering the following questions: 1) What are the perceived problems with the current VFS? 2) What options are available to us as remedies? 3) To what extent will existing FS code require revision in order to be useful after the rewrite? 4) Will Chapters 6,7,8 9 of "The Design and Implementation of the 4.4BSD Operating System" still pertain after the rewrite? 5) How important are questions 3 4 in the design of the new VFS? I believe that the VFS is conceptually sound and that the existing semantics should be strictly retained in the new code. Any new functionality should be added in the form of entirely new kernel routines and system calls, or possibly by such means as converting the existing routines to the vararg format etc. Here some of the problems I'm aware of, and my suggested remedies: 1.The interface is not reflexive, with regard to cn_pnbuf. Specifically, path buffers are allocated by the caller, but not freed by the caller, and various routines in each FS implementation are expected to deal with this. Each FS duplicates code, and such duplication is subject to error. Not to mention that it makes your kernel fat. Yep, that's not good. 2.Advisory locks are hung off private backing objects. Advisory locks are passed into VOP_ADVLOCK in each FS instance, and then each FS applies this by hanging the locks off a list on a private backing object. For FFS, this is the in core inode. A more correct approach would be to hang the lock off the vnode. This effectively obviates the need for having a VOP_ADVLOCK at all, except for the NFS client FS, which will need to propagate lock requests across the net. The most efficient mechanism for this would be to institute a pass/fail response for VOP_ADVLOCK calls, with a default of "pass", and an actual implementation of the operand only in the NFS client FS. I agree that it's better for all fs's to share this functionality as much as possible. I'd vote againsts your implimentation suggestion for VOP_ADVLOCK on an efficiency concern. If we actually make a VOP call, that should be the end of the story. I.e either add a vnode flag to indicate pas/fail-ness, or add a genfs/std call to handle the problem. I'd actually vote for the latter. Hang the byte-range locking off of the vnode, and add a genfs_advlock() or vop_stdadvlock() routine (depending on OS flavor) to handle the call. That way all fs's that can share code, and the callers need only call VO_ADVLOCK() - no other logic. NetBSD actually needs this to get unionfs to work. Do you want to talk privately about it? Again, each FS must duplicate the advisory locking code, at present, and such duplication is subject to error. Agreed. 3.Object locks are implemented locally in many FS's. The VOP_LOCK interface is implemented via vop_stdlock() calls in many FS's. This is done using the "vfs_default" mechanism. In other FS's, it's implemented locally. The intent of the VOP_LOCK mechanism being implemented as a VOP at all was to allow it to be proxied to another machine over a network, using the original Heidemann design. This is also the reason for the use of descriptors for all VOP arguments, since they can be opaquely
Re: Filesystem question...
On Mon, Aug 16, 1999 at 08:22:02PM +, Terry Lambert wrote: This is actually the problem at issue in an SMBFS implementation, and for which the Linux guys punted: the credential in SMB is per connection, not per user. Per connection creds suck performance wise (=I haven't seen an implementation which didn't). But, oh well.. There is some newer stuff in LANMan to deal with this inter-NT, and SAMBA incorporates this, but session ID's are not supported over a single VC by all LANMan servers. NetWare has the same problem, FWIW, as does NUC (a client FS for NetWare). At the risk of being flamed to death, you could use krb5 for that purpose.. Perhaps time to revive AFS? Seems that some of the issues here were solved in Transarc's/IBM's AFS that I used a while back (ok, it was a pain to run sometimes, but there's nothing per se that says you couldn't unbreak those things -- it's an implementation and availability of tools issue more than anything). Cheerios, Chris -- Christian Kuhtz, Sr. Network ArchitectBellSouth Corporation [EMAIL PROTECTED] -wk, [EMAIL PROTECTED] -hmAdvanced Data Services "Affiliation given for identification, not representation." Atlanta, GA, U.S. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: BSD XFS Port BSD VFS Rewrite
2. Advisory locks are hung off private backing objects. Advisory locks are passed into VOP_ADVLOCK in each FS instance, and then each FS applies this by hanging the locks off a list on a private backing object. For FFS, this is the in core inode. A more correct approach would be to hang the lock off the vnode. This effectively obviates the need for having a VOP_ADVLOCK at all, except for the NFS client FS, which will need to propagate lock requests across the net. The most efficient mechanism for this would be to institute a pass/fail response for VOP_ADVLOCK calls, with a default of "pass", and an actual implementation of the operand only in the NFS client FS. I agree that it's better for all fs's to share this functionality as much as possible. I'd vote againsts your implimentation suggestion for VOP_ADVLOCK on an efficiency concern. If we actually make a VOP call, that should be the end of the story. I.e either add a vnode flag to indicate pas/fail-ness, or add a genfs/std call to handle the problem. I'd actually vote for the latter. Hang the byte-range locking off of the vnode, and add a genfs_advlock() or vop_stdadvlock() routine (depending on OS flavor) to handle the call. That way all fs's that can share code, and the callers need only call VO_ADVLOCK() - no other logic. OK. Here's the problem with that: NFS client locks in a stacked FS on top the the NFS client FS. Specifically, you need to seperate the idea of asserting a lock against the local vnode, asserting the lock via NFS locking, and coelescing the local lock list, after both have succeeded, or reverting the local assertion, should the remote assertion fail. This is particularly important for transformative layers, specifically cryptographic or compressing layers. A similar issue exists for character sets, e.g. a Unicode enabled OS NFS mounting via NFS an ISO 8859-1 filesystem, and having to do the directory (de)bloat on the fly. NetBSD actually needs this to get unionfs to work. Do you want to talk privately about it? If you want. FreeBSD needs it for unionfs and nullfs, so it's something that would be worth airing. I think you could say that no locking routine was an approval of the uuper level lock. This lets you bail on all FS's except NFS, where you have to deal with the approve/reject from the remote host. The problem with this on FreeBSD is the VFS_default stuff, which puts a non-NULL interface on all FS's for all VOP's. 3. Object locks are implemented locally in many FS's. The VOP_LOCK interface is implemented via vop_stdlock() calls in many FS's. This is done using the "vfs_default" mechanism. In other FS's, it's implemented locally. The intent of the VOP_LOCK mechanism being implemented as a VOP at all was to allow it to be proxied to another machine over a network, using the original Heidemann design. This is also the reason for the use of descriptors for all VOP arguments, since they can be opaquely proxied to another machine via a general mechanism. Unlike NFS based network filesystems, this would allow you to add VOP's to both machines, without having to teach the transport about the new VOP for it to be usable remotely. Just for a point of comparison, I recently got almost all the NetBSD fs's to use common code. After our -Lite2 merge, all fs's were either calling the lock manager, or using genfs_nolock() (a version for non-locking fs's). Now there's a struct lock * and struct lock in struct vnode. The fs exports its locking behavior via the struct lock *. For most fs's, the struct lock * points to the struct lock, and genfs_lock() feeds that to the lock manager. But we've kept the ability to do something different (like call over the network) alive. If the struct lock * is NULL, you have to call VOP_LOCK on that fs. Note that this difference only matters for layered fs's - everything else should be calling VOP_LOCK() and letting the dispatch code figure out the right thing to do. Yes, this NULL is the same NULL I suggested for advisory locks, above. FreeBSD has moved to more common code, but it's all call-down based because of the vfs_default stuff again. 5. The idea of "root" vs. "non-root" mounts is inherently bad. Right now, there are several operations, all wrapped into a single "mount" entry point. This is actually a partial transition to a more cannonically correct implemetnation. The reason for the "root" vs. "non-root" knowledge in the code has to do with several logical operations: 1) "Mounting" the filesystem; that is, getting the vnode for the device to be mounted, and doing any FS specific operations necessary to cause the correct in-core context to be established. 2) Covering the
Re: Filesystem question...
On Mon, 16 Aug 1999, Terry Lambert wrote: The concept of private namespaces does not exist on FreeBSD. It would require a modification of the lookup mechanism, and, potentially, a seperation of credentials from the process into a session manager. Yeah but you can fake it pretty well without such mods. I've done it once already on linux and the same techniques I used would work on freebsd. But I can't get anyone interested :-( ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Filesystem question...
On Mon, 16 Aug 1999, Mike Smith wrote: But I can't get anyone interested :-( Uh, we're all interested; where's the code? v9fs is the first piece. The servers are done. But I'm mostly out of the freebsd hacking business at this point (except for maybe via drivers) so I need some help to get the rest of it plugged into freebsd. I'm no longer supported to do this kind of thing. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Saving system image to disk (NOT on a laptop)
Hi, To all you low-level kernel and bootloader hackers: what would it take to save and restore a running system image (presumably from dedicated raw partition) so that the system would continue where it left before reboot? It doesn't sound that difficult to me - after all, laptops somehow do it - but I know too little low-level stuff to try implementing it myself... Any comments? Some code? ;-) Andrzej Bialecki // [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com) // --- // -- FreeBSD: The Power to Serve. http://www.freebsd.org // --- Small Embedded FreeBSD: http://www.freebsd.org/~picobsd/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Raw Packet code containing security bits
Hello Andrew, When filling your struct ip *iphead, try replacing: iphead-ip_len = htons(length); with: iphead-ip_len = length; or, for portability reasons, you may want to do something like: #ifdef LINUX || OpenBSD21 #define BO(x) htons(x) #else #define BO(x) (x) #endif And, when filling the ip packet length, do a: iphead-ip_len = BO(length); This is a byte-order issue that has often caused confusion for Linux people... /usr/include/machine/endian.h provides some insight... /Bosko. I wonder if anyone here could perhaps of be assistance, Im currently playing with implementing certain things in trusted bsd to do with ip security classes and how the system responds to security bits, and implementing certain things the stack etc. However my first piece of test code playing with raw packets to test how things respond to packets with the security bit set, doesnt seem to want to work. This code compiles fine, however when I try and run it it says invalid argument when it tries to send the packet. If anyone could give me any insight as to why this code doesnt run properly, it would be much appreciated, and would certainly help me in my efforts to continue expanding trusted bsd. Ive included the code below... Thanks Andrew [snipped] - - - . . Bosko Milekic [EMAIL PROTECTED] http://www.dsuper.net/~bmilekic/ Network Operations - Delphi SuperNet, an Internet Direct company +1.514.281.7500 (vox) / +1.514.281.6599 (fax) / http://www.dsuper.net/ . . - - - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: BSD XFS Port BSD VFS Rewrite
On Mon, 16 Aug 1999, Terry Lambert wrote: 2.Advisory locks are hung off private backing objects. I'd vote againsts your implimentation suggestion for VOP_ADVLOCK on an efficiency concern. If we actually make a VOP call, that should be the end of the story. I.e either add a vnode flag to indicate pas/fail-ness, or add a genfs/std call to handle the problem. I'd actually vote for the latter. Hang the byte-range locking off of the vnode, and add a genfs_advlock() or vop_stdadvlock() routine (depending on OS flavor) to handle the call. That way all fs's that can share code, and the callers need only call VO_ADVLOCK() - no other logic. OK. Here's the problem with that: NFS client locks in a stacked FS on top the the NFS client FS. Ahh, but it'd be the fs's decision to map genfs_advlock()/vop_stdadvlock() to its vop_advlock_desc entry or not. In this case, NFS wouldn't want to do that. Though it would mean growing the fs footprint. Specifically, you need to seperate the idea of asserting a lock against the local vnode, asserting the lock via NFS locking, and coelescing the local lock list, after both have succeeded, or reverting the local assertion, should the remote assertion fail. Right. But my thought was that you'd be calling an NFS routine, so it could do the right thing. NetBSD actually needs this to get unionfs to work. Do you want to talk privately about it? If you want. FreeBSD needs it for unionfs and nullfs, so it's something that would be worth airing. I think you could say that no locking routine was an approval of the uuper level lock. This lets you bail on all FS's except NFS, where you have to deal with the approve/reject from the remote host. The problem with this on FreeBSD is the VFS_default stuff, which puts a non-NULL interface on all FS's for all VOP's. I'm not familiar with the VFS_default stuff. All the vop_default_desc routines in NetBSD point to error routines. Yes, this NULL is the same NULL I suggested for advisory locks, above. I'm not sure. The struct lock * is only used by layered filesystems, so they can keep track both of the underlying vnode lock, and if needed their own vnode lock. For advisory locks, would we want to keep track both of locks on our layer and the layer below? Don't we want either one or the other? i.e. layers bypass to the one below, or deal with it all themselves. 5.The idea of "root" vs. "non-root" mounts is inherently bad. You forgot: 5) Update export lists If you call the mount routine with no device name (args.fspec == 0) and with MNT_UPDATE, you get routed to the vfs_export routine This must be the job of the upper level code, so that there is a single control point for export information, instead of spreading it throughout ead FS's mount entry point. I agree it should be detangled, but think it should remain the fs's job to choose to call vfs_export. Otherwise an fs can't impliment its own export policies. :-) I thought it was? Admitedly the only reference code I have is the ntfs code in the NetBSD kernel. But given how full of #ifdef (__FreeBSD__)'s it is, I thought it'd be an ok reference. No. We've lost the context, but what I was trying to say was that I thought the marking-the-vnode-as-mounted-on bit was done in the mount syscall at present. At least that's what http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/vfs_syscalls.c?rev=1.130 seems to be doing. Basically, what you would have is the equivalent of a variable length "mounted volume" table, from which mappings (and exports, based on the mappings) are externalized into the namespace. Ahh, sounds like you're talking about a new formalism.. Right. It should just have a "mount" entry point, and the rest of the stuff moves to higher level code, called by the mount system call, and the mountroot stuff during boot, to externalize the root volume at the top of the hierarchy. An ideal world would mount a / that had a /dev under it, and then do transparent mounts over top of that. That would be quite a different place than we have now. ;-) The conversion of the root device into a vnode pointer, or a path to a device into a vnode pointer, is the job of upper level code -- specifically, the mount system call, and the common code for booting. My one concern about this is you've assumed that the user is mounting a device onto a filesystem. No. Vnoide, not bdevvp. The bdevvp stuff is for the boot time stuff in the upper level code, and only applies to the root volume. Maybe I mis-parsed. I thought you were talking about parsing the first mount option (in mount /dev/disk there, the /dev/disk option) into a vnode. The concern below is that different fs's have different ideas as to what that node should be. Some want it a device node which no one else is using (most leaf fs's), while some others want
Re: [Fwd: [URGENT] CVS problems]
Mark Jaffe wrote: CVS is issuing an "out of memory" message on attempting to checkin a 12MB file. What can I do? There is 300M of swap on the machine, it is running FreeBSD 2.2.8, and CVS says: "Concurrent Versions System (CVS) 1.9.26 (client/server)" Anyone help? How big is the history file size (compared to the processes' max allowed data size)? CVS has a number of brain-damanged areas; one in particular is that CVS reads the *ENTIRE* history file into memory when doing stuff ... and it's doing so simply to scan the history file line-by-line -- Darryl Okahata [EMAIL PROTECTED] DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Hewlett-Packard, or of the little green men that have been following him all day. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Using legacy sysinstall to upgrade live system
On Sat, Aug 14, 1999 at 12:29:42PM +0200, Sheldon Hearn wrote: On Fri, 13 Aug 1999 17:51:10 MST, dannyman wrote: Uhmmm, what if we don't have a floppy drive? Then you probably have a CDROM drive or a network interface, both of which can be used to get sysinstall onto your machine. :-) The point of it is, it's easy enough to download the floppies, but it's really hard to boot a system off an .flp image. :p Or, the real point of it is, that aside from "make world from source" there is no good way to update an existing system without doing something lame like having to boot ... off ... a floppy ... uncompressing kernel ... please wait ... But, on to my original question, has anybody been looking at a more "user friendly" "upgrade the darn thing *REAL EASY*" kind of setup? maybe invoke a networked pkg_add to run the latest sysinstall w dependencies? -dman -- dannyman - http://www.dannyland.org/~dannyman/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Using legacy sysinstall to upgrade live system
dannyman wrote: The point of it is, it's easy enough to download the floppies, but it's really hard to boot a system off an .flp image. :p 1. boot single-user 2. dd if=/some/dir/boot.flp of=/dev/da0s1b 3. reboot 4. When boot1 gives you the 5-second paused baton, press any key 5. enter "da(0,b)" at the Boot: prompt Us FreeBSD people can pretend we can do miniroot installs too :-) [ admittedly, I haven't tried this since before the new boot blocks were committed, but it worked perfectly last year... ] - mark Mark Newton Email: [EMAIL PROTECTED] (W) Network Engineer Email: [EMAIL PROTECTED] (H) Internode Systems Pty Ltd Desk: +61-8-82232999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: vnc on nat-proxy/firewall
vnc is cool, but also check out back-orafice (not sure where you get it but the new one can take over NT as well as W95) On Tue, 17 Aug 1999, Leif Neland wrote: I need to remote-control an NT behind a unix-box running nat-proxy/firewall/gateway. Would it be possible first to connect from the outside to a vnc-server on gateway, then to run vnc-client on the gateway to connect to a vnc-server on the nt? Or is it possible to have a vnc-proxy on the gateway to redirect to the nt? Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: BSD XFS Port BSD VFS Rewrite
2. Advisory locks are hung off private backing objects. I'd vote againsts your implimentation suggestion for VOP_ADVLOCK on an efficiency concern. If we actually make a VOP call, that should be the end of the story. I.e either add a vnode flag to indicate pas/fail-ness, or add a genfs/std call to handle the problem. I'd actually vote for the latter. Hang the byte-range locking off of the vnode, and add a genfs_advlock() or vop_stdadvlock() routine (depending on OS flavor) to handle the call. That way all fs's that can share code, and the callers need only call VO_ADVLOCK() - no other logic. OK. Here's the problem with that: NFS client locks in a stacked FS on top the the NFS client FS. Ahh, but it'd be the fs's decision to map genfs_advlock()/vop_stdadvlock() to its vop_advlock_desc entry or not. In this case, NFS wouldn't want to do that. Though it would mean growing the fs footprint. Nope; that's not really the problem. The problem is if I have two local processes that get into a race in order to obtain a remote lock. Because the remote lock is not asserted, there's no way to ensure that the order of service for the request is the same as the order of request -- consider cooperating programs, like sendmail and pine or elm (or whatever). The only way to resolve this is to ensure that the cooperating programs on the same system are lockstepped: at the client. The only way to do this is to assert the lock locally, then remotely, if the local assertion succeeds. In the case of our cooperating local processes, this resolves the race condition (depending on F_SETLCK/F_SETLCKW, they behave as if the locks were local. Which is what you want. Specifically, you need to seperate the idea of asserting a lock against the local vnode, asserting the lock via NFS locking, and coelescing the local lock list, after both have succeeded, or reverting the local assertion, should the remote assertion fail. Right. But my thought was that you'd be calling an NFS routine, so it could do the right thing. The problem is that the local lock doesn't belong to NFS. Even if it did (I think this would be an error for a remotely mounted "whiteout" in a "translucent" local FS), the problem is that in doing the local assertion, you will intrinsically coeelesce locks. Now if the lock mode you are requesting overlaps a previous lock, and the modes are not exactly the same, there's no way to back out the local promotion or demotion without a coelesce. This doesn't resolve the most complex cases you could contrive, with multiple stacking layers that don't support a distributed coherency protocol for locks for two or more players, but it handles the local vs. NFS issues acceptably. NetBSD actually needs this to get unionfs to work. Do you want to talk privately about it? If you want. FreeBSD needs it for unionfs and nullfs, so it's something that would be worth airing. I think you could say that no locking routine was an approval of the uuper level lock. This lets you bail on all FS's except NFS, where you have to deal with the approve/reject from the remote host. The problem with this on FreeBSD is the VFS_default stuff, which puts a non-NULL interface on all FS's for all VOP's. I'm not familiar with the VFS_default stuff. All the vop_default_desc routines in NetBSD point to error routines. In FreeBSD, they now point to default routines that are *not* error routines. This is the problem. I admit the change was very well intentioned, since it made the code a hell of a lot more readable, but choosing between readable and additional function, I take function over form (I think the way I would have "fixed" the readability is by making the operations that result in the descriptor set for a mounted FS instance be both discrete, and named for their specific function). Yes, this NULL is the same NULL I suggested for advisory locks, above. I'm not sure. The struct lock * is only used by layered filesystems, so they can keep track both of the underlying vnode lock, and if needed their own vnode lock. For advisory locks, would we want to keep track both of locks on our layer and the layer below? Don't we want either one or the other? i.e. layers bypass to the one below, or deal with it all themselves. I think you want the lock on the intermediate layer: basically, on every vnode that has data associated with it that is unique to a layer. Let's not forget, also, that you can expose a layer into the namespace in one place, and expose it covered under another layer, at another. If you locked down to the backing object, then the only issue you would be left with is one or more intermediate backing objects. For a layer with an intermediate backing object, I'm prepared to declare it "special", and proxy the operation down to any inferior backing object (e.g. a union FS that adds files from two FS's together, rather than
How much memory (max) will FreeBSD use?
I've looked at http://www.freebsd.org/FAQ/FAQ51.html, but the answer seems to be lacking... On a stock system (3.2 and 4.0), how much RAM will a system be able to use? Will a stock system use all 4GB? Thanks, -- Stephen J. Roznowski([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
[Fwd: [URGENT] CVS problems]
Mark Jaffe wrote: Jordan, CVS is issuing an "out of memory" message on attempting to checkin a 12MB file. What can I do? There is 300M of swap on the machine, it is running FreeBSD 2.2.8, and CVS says: "Concurrent Versions System (CVS) 1.9.26 (client/server)" I'll post this to the lists, too. -- Anyone help? -- --- Mark Jaffe | Build Meister Ricoh Silicon Valley | ADC (408) 863-8066 | [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Kerberos 5 integration.
Who were the parties that were heading up the Kerberos 5 integration? I have questions. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How much memory (max) will FreeBSD use?
On Mon, 16 Aug 1999 22:45:28 -0400, "Stephen J. Roznowski" wrote: On a stock system (3.2 and 4.0), how much RAM will a system be able to use? Will a stock system use all 4GB? I expect that someone else will answer your question. I just want to clear up a possible misunderstanding that could cost you a lot of wasted time later. The word "stock" doesn't apply to 4.0 . That's the development edge of FreeBSD, which is not recommended for use in production environments by people who aren't prepared to bleed graciously. :-) Make sure you're familiar with the information at the following URLs before choosing to run 4.0-CURRENT: http://www.freebsd.org/handbook/cutting-edge.html http://www.freebsd.org/FAQ/FAQ7.html Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Kerberos 5 integration.
On Tue, 17 Aug 1999 00:51:27 -0400, "Matthew N. Dodd" wrote: Who were the parties that were heading up the Kerberos 5 integration? I have questions. Seek Ye first the kingdom of Mark. (markm) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: BSD XFS Port BSD VFS Rewrite
In message [EMAIL PROTECTED] Narvi writes: : Nintendo 64 uses MIPS. : : : Which doesn't matter all that much. MIPS cpus for nintendo could be made : by say MISP, not SGI (and SGI sold/is trying to sell MIPS). Acutally, the Nintendo 64 uses the Vr4300 series of chips from NEC. I think the new Nintendo will use a different (non-mips) processor, but I'm not completely sure what the new one will be (when NEC announced this, MIPS stock took a dive). SGI has already spun out MIPS and has been slowly reducing its stake in MIPS for some time now. However, there is another gaming machine based on a 128bit MIPS design in the pipeline from, I think, Sony. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How do you allocate dma channel with newbus?
I am feeling a little dense today, how do you allocate a dma channel for a PCI busmaster device with newbus? It's a bus master, so you don't. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msm...@freebsd.org \\-- Joseph Merrick \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: BSD XFS Port BSD VFS Rewrite
On Sat, Aug 14, 1999 at 12:23:00PM -0400, Brian F. Feldman wrote: On Sat, 14 Aug 1999, James Howard wrote: I heard somewhere that Linux was released under a slightly modified GPL to permit the inclusion of BSD code. I assumed they did this to steal the IP stack. Most likely. Nope. Linux has always had it's own IP stack. That's where the Linux's network performance is poor arguments came from. Of course, it's a lot better these days. -- Dom Mitchell -- Palmer Harvey McLane -- Unix Systems Administrator Finally, when replying to messages only quote the parts of the message your will be discussing or that are relevant. Quoting whole messages and adding two lines at the top is not good etiquette. -- Elias Levy -- ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ** To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: How do you allocate dma channel with newbus?
Of all the gin joints in all the towns in all the world, Mike Smith had to walk into mine and say: I am feeling a little dense today, how do you allocate a dma channel for a PCI busmaster device with newbus? It's a bus master, so you don't. The logical conclusion is that Larry really does have a question, but he asked it badly. Since he asked it so badly that we really don't know what he meant, we should attempt to throw information at him in the hopes that we'll end up telling him what he wants. This is not as efficient as asking the question correctly the first time, but communication seems to be a lost art these days, so what can you do. First of all, with newbus, you now have pci_read_config() and pci_write_config() instead of pci_conf_read() and pci_conf_write(). The former accept a device_t and let you specify the register width (as opposed to forcing to you to use 32-bit accesses all the time). You may need to enable bus mastering and PIO/memory mapping mode in the PCI command register as before. Once you do that, you have to allocate the resources that you need. The first resource is the register access space. This can be either an I/O address in iospace or a memory base address. The second is the interrupt. You need to keep track of these resources in your softc structure. They are allocated with bus_alloc_resource(). For PCI devices, you used to use pci_map_port() or pci_map_mem(); now you use bus_alloc_resource() instead, which ultimately has the same effect. When you allocate the register space resource, you have to pass a pointer to a resource ID, which for PCI devices is the register to use. For the SYS_RES_IOPORT resource type, you specify the PCI iobase address register. For SYS_RES_MEMORY, you specify the the memory base address register. Once you have allocated the iospace resource, you can then use rman_get_bustag() and rman_get_bushandle() to get the bustag and bushandle that you can use with the bus_space_read()/bus_space_write() routines to read/write the device registers. The bustag and bushandle should be treated as opaque; they will let you read from iospace or memory mapped space depending on the resource type that you allocated. You also use bus_space_alloc() to allocate the interrupt resource using SYS_RES_IRQ (the resource ID is 0). To actually map the interrupt to a handler function, you need to use bus_setup_intr(). Resources can be released with bus_release_resource(), and the interrupt handler can be detached with bus_teardown_intr(). This allows you to unload drivers. For bus master DMA, you can still use vtophys() to map kernel virtual addresses to physical addresses as before. Ideally one should use the busdma routines for that, however I haven't figured out how to use them with network device drivers yet, and nobody has come forward with a nice simple example that shows how to do it (and no, I don't mean a NetBSD driver: I mean an example which will actually work in FreeBSD). The fxp, xl, sf, sk, ti and other drivers have been newbused and use bus master DMA; hopefully these should provide decent examples. -Bill -- = -Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu Work: wp...@ctr.columbia.edu | Center for Telecommunications Research Home: wp...@skynet.ctr.columbia.edu | Columbia University, New York City = It is not I who am crazy; it is I who am mad! - Ren Hoek, Space Madness = To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: [Review please] (was: Re: cvs commit: src/gnu/usr.bin/man/manpath manpath.config)
Ruslan Ermilov r...@freebsd.org writes: How about the following patch. It adds an OPTIONAL_MANPATH directive, which is equivalent to the MANDATORY_MANPATH, except an absence of the directory is not considered an error. Sure. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Configuration mechanism of PCI bus
On 1999-08-09 22:08 -0400, Zhihui Zhang zzh...@cs.binghamton.edu wrote:
Even with PCI System Architecture, 4th edition at hand, I still have
some problems understanding the code in isa/pcibus.c. Please point out
any misunderstanding I may have in the following:
It has been some time since I write that code, but I'll try to remember
why it became the way you found it ... ;-)
(1) At first, you can not modify the address port at 0xcf8 without a FULL
32-bit write. The routine pci_cfgopen() seems to use this fact.
Yes.
(2) The constant CONF1_ENABLE_MSK includes 4 higher bus number bits, only
4 bits can be used as bus number, so we can have at most 16 PCI buses.
This is partially true. The code assumes (and I have yet to meet a PCI
BIOS that violates that assumption), that the address register will not
have any of the bits masked by 0x7ff0 set. This is generally true,
since the **last** prior access to PCI config space by the BIOS will
have been to a PCI bridge (i.e. to a bus number much lower than the
highest PCI bus number in the system).
You are correct: If the previous config cycle was to a bus higher than 15,
then this heuristic will assume that there is no configuration mechanism 1
address register. I had to add that heuristic in order to prevent the PCI
porbe from crahsing EISA only systems.
(3) The variable mode1res seems to refer to any residual left by BIOS in
the address port. If it is non-zero, we will try to find a device using
configuration mechanism 1.
Yes. Writing 0xff00 should result in 0x8000 being read back.
Only the MSB is writable, the remaining high order bits are wired to 0.
This is another test that is most likely to fail for non-PCI systems.
(3) The magic constant 0xf870ff excludes many devices. How it is chosen?
I guess those excluded devices are not important or supported by FreeBSD.
It seems to me that if pci_cfgcheck() finds at least one device, then the
configuration mechanism is regarded as correctly detected.
Yes. After testing for config mechanism 1 or 2, another last test is done
to make sure, there is at least one PCI device on the bus. The mask is
chosen in such a way, that there is at least one device on PCI bus 0, which
satisfies the following conditions:
class in 0..7
subclass in 0..15 or equal 0x80 (in fact 0x80 .. 0x8f are accepted)
prog if equal 0
and finally
class not equal 0 or subclass not equal 0
This will for example be true for a PCI VGA card (present in just about
every system), which has class=0 and subclass=1 or class=3 and subclass
in {0,1,0x80}. But in any PCI 2.0 or later system, the chip-set will also
be present on PCI bus 0 and will cause a match with class=6 and subclass
in 0 .. 7 (or 0x80). Any disk or network controller should also suffice
to make this test succeed.
The only case that will have this test fail is an ancient (pre PCI-2.0)
system with no PCI VGA card.
Regards, STefan
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: How do you allocate dma channel with newbus?
Larry Lile wrote: I am feeling a little dense today, how do you allocate a dma channel for a PCI busmaster device with newbus? You don't. PCI busmastering doesn't use dma channels. Cheers, -Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: shared memory crash
don't use shmget if you can. Use mmap'ed files. The SYSV shm interface is incredibly dumb. ron To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
PCCard can't get CIS for 3com card
rtoren writes: The card came with the Dell Inspiron and is a 3com 3CCFEM656B. Unfortunately, I don't think 3.2R is getting enough data to attempt an ID. I saw an archived query just like my situation in the mail archives from a year ago, but there was no reply. Once I get past this, I can worry about the pccard.conf and such. I think that this is a cardbus card. If so, it is not supported. I had to buy a cheap NE2000 clone for my Inspiron 7K. The good news is that they are cheap; the bad news is that your fancy ethernet card is going to sit in a drawer until cardbus support is finished. Boot time entries appear to be: fred /kernel: PC-Card VLSI 82C146 (5mem 2 I/O windows) fred /kernel: pcic: controller irq 3 fred /kernel: Initializing PC-card drivers: ep sio fred /kernel: Card inserted, slot 0 fred pccardd[64]: No card in database for () fred pccardd[64] pccard started Command line probing gives fred# pccardc dumpcis Configuration data for card in slot 0 Tuple #1, code = 0xff (Terminator), length = 0 2 slots found Any assistance would be greatly appreciated Rip Toren rto...@bronzedragon.net To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message -- M. L. Dodsonbdod...@scms.utmb.edu 409-772-2178FAX: 409-772-1790 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: BSD XFS Port BSD VFS Rewrite
On Fri, 13 Aug 1999, Terry Lambert wrote: Has anyone mentioned to them that they will be unable to incorporate changes made to the GPL'ed version of XFS back into the IRIX version of XFS, without IRIX becoming GPL'ed? Given that they say they're dropping IRIX and going with Linux, I don't think it'll be a problem. Can you please site a reference for this, other than wishful thinking by the Linux camp? PS: I fired off a note to Dr. Forest Baskett at SGI (their senior VP for R D, and their CTO) about the license, and FS researchers in the BSD community (e.g. Dr. Margo Seltzer, Dr. Kirk McKusick, John Heidemann, et. al.) which will be unable to participated in driving their technology forward because of the license. I will report the response (if any). Terry Lambert te...@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: IDE quirk in 3.2-STABLE kernel ?
Hi folks, I didn't see any pointers other than pilot error raised in the recent thread with subject line: Subject: Re: IDE quirk in 3.2-STABLE kernel ? Perhaps those of you who're in support of the pilot error notion could have a look at PR 13174 and comment? The originator claims that his kernel only finds wdc0 when he auto-detects his hard drives with his Award BIOS. He doesn't specify whether he has drives connected to that controller, which is why I've cc'd him on this mail. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: BSD XFS Port BSD VFS Rewrite
On Mon, 16 Aug 1999, Terry Lambert wrote: On Fri, 13 Aug 1999, Terry Lambert wrote: Has anyone mentioned to them that they will be unable to incorporate changes made to the GPL'ed version of XFS back into the IRIX version of XFS, without IRIX becoming GPL'ed? Given that they say they're dropping IRIX and going with Linux, I don't think it'll be a problem. Can you please site a reference for this, other than wishful thinking by the Linux camp? Here's one: http://www.zdnet.com/pcweek/stories/news/0,4153,1015908,00.html But just about every trade rag covered it. Vince. -- == Vince Vielhaber -- KA8CSH email: v...@michvhf.com flame-mail: /dev/null # include std/disclaimers.h TEAM-OS2 Online Campground Directoryhttp://www.camping-usa.com Online Giftshop Superstorehttp://www.cloudninegifts.com == To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: BSD XFS Port BSD VFS Rewrite
On Fri, 13 Aug 1999, Terry Lambert wrote: Has anyone mentioned to them that they will be unable to incorporate changes made to the GPL'ed version of XFS back into the IRIX version of XFS, without IRIX becoming GPL'ed? Given that they say they're dropping IRIX and going with Linux, I don't think it'll be a problem. Can you please site a reference for this, other than wishful thinking by the Linux camp? Here's one: http://www.zdnet.com/pcweek/stories/news/0,4153,1015908,00.html But just about every trade rag covered it. Begging your pardon, but: | --- With the help of Veritas Software Corp., SGI will work to add | key features of its Irix operating system to the Linux platform. | Currently, Irix runs on the MIPS platform. Once SGI switches | entirely to Intel Corp.'s IA/64 platform, that will be the end of | Irix. | | SGI is also forming an alliance with NEC Corp. to increase its | market share in Japan. These paragraphs are contradictory. It implies an end to MIPS. Nintendo 64 uses MIPS. It also seems a bit overzealous. Terry Lambert te...@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: BSD XFS Port BSD VFS Rewrite
On Mon, 16 Aug 1999, Terry Lambert wrote: On Fri, 13 Aug 1999, Terry Lambert wrote: Has anyone mentioned to them that they will be unable to incorporate changes made to the GPL'ed version of XFS back into the IRIX version of XFS, without IRIX becoming GPL'ed? Given that they say they're dropping IRIX and going with Linux, I don't think it'll be a problem. Can you please site a reference for this, other than wishful thinking by the Linux camp? Here's one: http://www.zdnet.com/pcweek/stories/news/0,4153,1015908,00.html But just about every trade rag covered it. Begging your pardon, but: | --- With the help of Veritas Software Corp., SGI will work to add | key features of its Irix operating system to the Linux platform. | Currently, Irix runs on the MIPS platform. Once SGI switches | entirely to Intel Corp.'s IA/64 platform, that will be the end of | Irix. | | SGI is also forming an alliance with NEC Corp. to increase its | market share in Japan. These paragraphs are contradictory. It implies an end to MIPS. Nintendo 64 uses MIPS. It also seems a bit overzealous. No argument here. Perhaps they're just trying to float a few trial baloons in hopes of finding something popular/feasable. Vince. -- == Vince Vielhaber -- KA8CSH email: v...@michvhf.com flame-mail: /dev/null # include std/disclaimers.h TEAM-OS2 Online Campground Directoryhttp://www.camping-usa.com Online Giftshop Superstorehttp://www.cloudninegifts.com == To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: BSD XFS Port BSD VFS Rewrite
--- Terry Lambert tlamb...@primenet.com wrote: On Fri, 13 Aug 1999, Terry Lambert wrote: Can you please site a reference for this, other than wishful thinking by the Linux camp? Here's one: http://www.zdnet.com/pcweek/stories/news/0,4153,1015908,00.html But just about every trade rag covered it. Begging your pardon, but: | --- With the help of Veritas Software Corp., SGI will work to add | key features of its Irix operating system to the Linux platform. | Currently, Irix runs on the MIPS platform. Once SGI switches | entirely to Intel Corp.'s IA/64 platform, that will be the end of | Irix. | | SGI is also forming an alliance with NEC Corp. to increase | its market share in Japan. These paragraphs are contradictory. It implies an end to MIPS. Contradictory how? NEC's a big PC manufacurer in Japan. If SGI is moving toward more conventional off-the-shelf components, they stand to gain tremendously by an alliance, both from manufacturing and distribution standpoints. Nintendo 64 uses MIPS. It also seems a bit overzealous. So do the old and new Playstation models. The MIPS core is being manufactured by several companies: IDT alone has something like a dozen variants available with and without MMU, FP, 5000 vs 1 core, etc. and is in far wider use than in just PCs and gaming consoles. I doubt if SGI machines abandoning MIPS processors would put much of a dent in MIPS' profitability. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: BSD XFS Port BSD VFS Rewrite
I lost track of the quotes. | --- With the help of Veritas Software Corp., SGI will work to add | key features of its Irix operating system to the Linux platform. | Currently, Irix runs on the MIPS platform. Once SGI switches | entirely to Intel Corp.'s IA/64 platform, that will be the end of | Irix. | | SGI is also forming an alliance with NEC Corp. to increase its | market share in Japan. These paragraphs are contradictory. It implies an end to MIPS. an end to irix and an end to MIPS on desktop and server platforms has no big effect on MIPS processors. The big volume for MIPS is embedded, or so I am told. For an interesting take on all this visit www.mipsabi.org ron To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
RE: IDE quirk in 3.2-STABLE kernel ?
I didn't see any pointers other than pilot error raised in the recent thread with subject line: Subject: Re: IDE quirk in 3.2-STABLE kernel ? Perhaps those of you who're in support of the pilot error notion could have a look at PR 13174 and comment? The originator claims that his kernel only finds wdc0 when he auto-detects his hard drives with his Award BIOS. He doesn't specify whether he has drives connected to that controller, which is why I've cc'd him on this mail. I apologize for the missing information. This problem has been posted several times (by me) to the -stable mailing list, and I simply forgot to include all the details with the bug report. The only reason why this would be a critical bug is if there were drives connected to the primary controller. In this case, I only have IDE drives, which means that the kernel cannot mount the root filesystem without wcd0 being detected. I have two drives on wcd0: a 1.27 GB Samsung as master (with root filesystem) and a 6.54 GB Seagate (with /usr, and others). I have an ATAPI CD-ROM drive as master on wcd1 (which is detected just fine). I've noticed this behaviour with every 3.- branch installation I've had on my machine (3.2-RELEASE boot disks, 3.2-STABLE). I have 4 other OSs on the same machine, so I would prefer not to mess with the physical configuration (i.e. moving disks from one controller to another, etc), which would mess up their drive configurations. Please note that this is not a problem with IRQ's, etc. I've had 2.2.8-RELEASE and -STABLE running on the same machine with absolutely no problems detecting wcd0 (and the default IRQ's and port addresses for both 2.2.8 and 3.2 are the same). Any help is appreciated. Andrew J. Lofthouse To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Whither makefiles for src/crypto/telnet/* ?
Date: Sat, 14 Aug 1999 14:35:34 -0700 (PDT)
From: Kris Kennaway k...@hub.freebsd.org
I also have prototype code which can store multiple password hashes in the
password file, and retrieves secondaries in a new field in struct
passwd. You could conceivably set it up to keep a DES password in sync
with the SRP one, and distribute only the DES over NIS. I don't know how
extensible NIS is, but maybe we could hide the other hashes in there as
well for those who understand them.
I'm hardly an expert with NIS, but it is actually fairly flexible...
as long as changes imposed are on its own terms. :-)
For example, you can easily create a new NIS map (as was done with the
master.passwd.by{name,uid} maps). However, systems that don't know to
look anything up in such a construct will not pay attention to it.
(For example, a Solaris system hasn't a clue that the map
master.passwd.byname exists, much less that it shoudl be used for
anything, so login on such a system ignores that map and tries to do
password verification using the passwd.byname map. If the NIS master
server is a FreeBSD box, by default the passwd.byname map merely has *
as the encrypted password, while placing the encrypted password in
master.passwd.byname. This is why it's necessary, in such a situation,
to set the UNSECURE flag -- that way, the FreeBSD box will place the
encrypted password in passwd.byname, which placates the Solaris box(en).
On a FreeBSD system, there are special checks to see if the process
accessing the master.passwd.by{name,uid} maps has an euid of 0; if so,
the access is permitted; if not, it isn't. But the Solaris box, since
it never knew about the map, certainly doesn't treat it specially, so
though there's no code to access it to make any decisions, J. Random
User is quite able to do (say) a ypcat -k master.passwd.byname from
the Solaris box.)
In an (arguably) similar vein, it is possible to use (new) NIS maps to
hold (say) amd maps. (We do this here.) One merely needs to add the
appropriate stanza(s) to the /var/yp/Makefile, and be sure that there is
code in the appropriate places to go look for information in the NIS
maps in question to the /var/yp/Makefile, and be sure that there is
code in the appropriate places to go look for information in the NIS
maps in question.
So you could create new NIS maps to hold nearly any (textual) key/value
pairs you feel like creating. (Unique keys for a given map would make
this easier.)
Whether or not actually using such a mechanism for decision-making is a
Good Idea(tm) is a rather different issue, though (and is likely to be
implementation (among other things) -dependent).
Hope someone finds a bit of this of use,
david
--
David Wolfskill d...@whistle.comUNIX System
Administrator
voice: (650) 577-7158 pager: (888) 347-0197 FAX: (650) 372-5915
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
RE: IDE quirk in 3.2-STABLE kernel ?
I didn't see any pointers other than pilot error raised in the recent thread with subject line: Subject: Re: IDE quirk in 3.2-STABLE kernel ? Perhaps those of you who're in support of the pilot error notion could have a look at PR 13174 and comment? The originator claims that his kernel only finds wdc0 when he auto-detects his hard drives with his Award BIOS. He doesn't specify whether he has drives connected to that controller, which is why I've cc'd him on this mail. NOTE on last e-mail: I mis-typed the device names; should be 'wdc0' and 'wdc1' (instead of 'wcd0' and 'wcd1') I apologize for the missing information. This problem has been posted several times (by me) to the -stable mailing list, and I simply forgot to include all the details with the bug report. The only reason why this would be a critical bug is if there were drives connected to the primary controller. In this case, I only have IDE drives, which means that the kernel cannot mount the root filesystem without wcd0 being detected. I have two drives on wcd0: a 1.27 GB Samsung as master (with root filesystem) and a 6.54 GB Seagate (with /usr, and others). I have an ATAPI CD-ROM drive as master on wcd1 (which is detected just fine). I've noticed this behaviour with every 3.- branch installation I've had on my machine (3.2-RELEASE boot disks, 3.2-STABLE). I have 4 other OSs on the same machine, so I would prefer not to mess with the physical configuration (i.e. moving disks from one controller to another, etc), which would mess up their drive configurations. Please note that this is not a problem with IRQ's, etc. I've had 2.2.8-RELEASE and -STABLE running on the same machine with absolutely no problems detecting wcd0 (and the default IRQ's and port addresses for both 2.2.8 and 3.2 are the same). Any help is appreciated. Andrew J. Lofthouse To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Whither makefiles for src/crypto/telnet/* ?
On Mon, 16 Aug 1999, David Wolfskill wrote: I'm hardly an expert with NIS, but it is actually fairly flexible... as long as changes imposed are on its own terms. :-) Thanks for the information. I noticed some rumblings on the srp-dev mailing list about developing NIS support - I don't think anything has come of it yet, but that would be the place to discuss it so we can get some kind of cross-platform compatability. I'll certainly look into that further when I can start working on this again. Kris To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: BSD XFS Port BSD VFS Rewrite
I lost track of the quotes. | --- With the help of Veritas Software Corp., SGI will work to add | key features of its Irix operating system to the Linux platform. | Currently, Irix runs on the MIPS platform. Once SGI switches | entirely to Intel Corp.'s IA/64 platform, that will be the end of | Irix. | | SGI is also forming an alliance with NEC Corp. to increase its | market share in Japan. These paragraphs are contradictory. It implies an end to MIPS. an end to irix and an end to MIPS on desktop and server platforms has no big effect on MIPS processors. The big volume for MIPS is embedded, or so I am told. For an interesting take on all this visit www.mipsabi.org Uh, that site is dead, as of the end of this month. See the first link (announcement). Terry Lambert te...@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: BSD XFS Port BSD VFS Rewrite
These paragraphs are contradictory. It implies an end to MIPS. Nintendo 64 uses MIPS. It also seems a bit overzealous. No argument here. Perhaps they're just trying to float a few trial baloons in hopes of finding something popular/feasable. That was my take on things, since no source was attributed. Either that, or press zealotry. Terry Lambert te...@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: BSD XFS Port BSD VFS Rewrite
On Mon, 16 Aug 1999, Terry Lambert wrote: On Fri, 13 Aug 1999, Terry Lambert wrote: Has anyone mentioned to them that they will be unable to incorporate changes made to the GPL'ed version of XFS back into the IRIX version of XFS, without IRIX becoming GPL'ed? Given that they say they're dropping IRIX and going with Linux, I don't think it'll be a problem. Can you please site a reference for this, other than wishful thinking by the Linux camp? Here's one: http://www.zdnet.com/pcweek/stories/news/0,4153,1015908,00.html But just about every trade rag covered it. Begging your pardon, but: | --- With the help of Veritas Software Corp., SGI will work to add | key features of its Irix operating system to the Linux platform. | Currently, Irix runs on the MIPS platform. Once SGI switches | entirely to Intel Corp.'s IA/64 platform, that will be the end of | Irix. | Why would switch to IA/64 mean end of IRIX? SGI has long planned to switch to IA/64, but with IRIX. If SGI wants to continue building Origins, esp the high CPU count ones, IRIX is to stay for a long time. | SGI is also forming an alliance with NEC Corp. to increase its | market share in Japan. These paragraphs are contradictory. It implies an end to MIPS. An end to high-end MIPS may come ... if Merced, etc. peform well enough. As this is a topic beaten to death on comp.arch, everybody interested should look there. Nintendo 64 uses MIPS. Which doesn't matter all that much. MIPS cpus for nintendo could be made by say MISP, not SGI (and SGI sold/is trying to sell MIPS). It also seems a bit overzealous. You bet. It seems it is to hard foir the journalists to actually read the press releases. Terry Lambert te...@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. Sander There is no love, no good, no happiness and no future - all these are just illusions. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: BSD XFS Port BSD VFS Rewrite
At 4:19 PM + 8/16/99, Terry Lambert wrote: Begging your pardon, but: | --- With the help of Veritas Software Corp., SGI will work to add | key features of its Irix operating system to the Linux platform. | Currently, Irix runs on the MIPS platform. Once SGI switches | entirely to Intel Corp.'s IA/64 platform, that will be the end | of Irix. | | SGI is also forming an alliance with NEC Corp. to increase its | market share in Japan. These paragraphs are contradictory. It implies an end to MIPS. Nintendo 64 uses MIPS. I don't think those paragraphs are all that contradictory. They just imply the end of SGI selling MIPS-based workstations running IRIX. Nintendo can keep using MIPS, and my guess is that Nintendo is not running IRIX on their machines. What is the contradiction? I'm making the assumption here that Nintendo sells more Nintendo 64 games than SGI sells workstations, and thus SGI dropping MIPS for workstations does *-NOT-* imply the end of MIPS. It only implies the end of IRIX. In any case, even if it is contradictory in some sense, there is no question that SGI is *claiming* that they are all buddy-buddy with linux, and thus they are already comfortable with gnu-licensed software. --- Garance Alistair Drosehn = g...@eclipse.acs.rpi.edu Senior Systems Programmer or dro...@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Whither makefiles for src/crypto/telnet/* ?
Sorry for not responding to this earlier, I missed it in my inbox. On Sat, 14 Aug 1999, Nick Sayer wrote: Where do you store the keys, or do you generate them dynamically? The latter would take time to verify primality. If by keys you mean the DH generator and such, they are constants in the code at present. It is possible to extend the protocol in such a way as to pass them from server to client, but at present it does not do this. Having them be constant does not significantly weaken DH. If they weren't, you'd have to pass them from the server at session start. Are you sure about this? Having constant p, g, x and y for every telnet client and server surely makes it much easier to attack? In theory you could probably pregenerate all of the arithmetic. Because it does not interoperate with legacy servers over NIS? Any other reasons? If you're saying that you're going to have a new format of the second field of the master passwd file ($3$[^:]* ?), then I suppose the only other one left is having to convert legacy password files and manage the N and g values that SRP requires. You'll have to fix things that add users to have them default to the new scheme. Probably a PAM module which rehashes passwords into the new format. I'd expect one such module already exists. So you'd set up the PAM module to run as part of the login module stack and tell libcrypt that the user gets a default password of SRP. Alternatively, expire all their passwords and when they pick a new one it will be SRP. And don't sniff at breaking NIS. Most sites I deal with use it. And I don't know of any site that uses NIS that isn't heterogenous, which requires the legacy password format. As David Wolfskill explained this should be solvable. In my scheme I distribute these as part of the password hash. N and g are both public values known to both client and server(s). SRP has them in configuration files. They have to be set up. Yes, on the server. This is a non-issue. Kris To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: BSD XFS Port BSD VFS Rewrite
I don't think that this is an appropriate forum but I will put in my two cents nonetheless. At least as of a couple of years age MIPS was the most widely used embedded processor in the world. Thus, MIPS is in no way dependent on IRIX. Not to mention that Linux runs on MIPS. -Kip On Mon, 16 Aug 1999, Garance A Drosihn wrote: At 4:19 PM + 8/16/99, Terry Lambert wrote: Begging your pardon, but: | --- With the help of Veritas Software Corp., SGI will work to add | key features of its Irix operating system to the Linux platform. | Currently, Irix runs on the MIPS platform. Once SGI switches | entirely to Intel Corp.'s IA/64 platform, that will be the end | of Irix. | | SGI is also forming an alliance with NEC Corp. to increase its | market share in Japan. These paragraphs are contradictory. It implies an end to MIPS. Nintendo 64 uses MIPS. I don't think those paragraphs are all that contradictory. They just imply the end of SGI selling MIPS-based workstations running IRIX. Nintendo can keep using MIPS, and my guess is that Nintendo is not running IRIX on their machines. What is the contradiction? I'm making the assumption here that Nintendo sells more Nintendo 64 games than SGI sells workstations, and thus SGI dropping MIPS for workstations does *-NOT-* imply the end of MIPS. It only implies the end of IRIX. In any case, even if it is contradictory in some sense, there is no question that SGI is *claiming* that they are all buddy-buddy with linux, and thus they are already comfortable with gnu-licensed software. --- Garance Alistair Drosehn = g...@eclipse.acs.rpi.edu Senior Systems Programmer or dro...@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
illegal ATAPI command in wdc probe?
The VMWare guest OS page for FreeBSD (http://www.vmware.com/support/technotesfreebsd.html) states, --- One caveat with all versions of FreeBSD is that there is a problem probing for the CD-ROM device wdc1; FreeBSD sends an illegal ATAPI command to the IDE controller and ignores the error status reply. This results in approximately a 1 minute delay each time the system boots. --- Is this true? Charles To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: How do you allocate dma channel with newbus?
On Sun, 15 Aug 1999, Larry Lile wrote: I am feeling a little dense today, how do you allocate a dma channel for a PCI busmaster device with newbus? I don't think PCI devices use the ISA DMA controller. It just works. (EISA has this advantage too.) -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | win...@jurai.net | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
[Fwd: [URGENT] CVS problems]
Mark Jaffe wrote: Jordan, CVS is issuing an out of memory message on attempting to checkin a 12MB file. What can I do? There is 300M of swap on the machine, it is running FreeBSD 2.2.8, and CVS says: Concurrent Versions System (CVS) 1.9.26 (client/server) I'll post this to the lists, too. -- Anyone help? -- --- Mark Jaffe | Build Meister Ricoh Silicon Valley | ADC (408) 863-8066 | mja...@rsv.ricoh.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Whither makefiles for src/crypto/telnet/* ?
Kris Kennaway wrote: Are you sure about this? Having constant p, g, x and y for every telnet client and server surely makes it much easier to attack? In theory you could probably pregenerate all of the arithmetic. Maybe we're not using the constant names the same way. In SRA the modulus and base are constants. I don't think that those being public helps an attacker too much. The client and server must agree on these values before you start an authentication, so at the very least a single failed authentication attempt would provide these values to an attacker anyway. And it's computationally too difficult to generate suitable values on the fly. Each side picks Xmine, each side passes Nmine=B^Xmine % m, each then computes K=B^(Nhis*Xmine) % m. That's straight DH, right? SRA then uses the common K to make a DES key to pass auth data from client to server. Simple. You can attack the protocol either by brute forcing DES, factoring the DH exchange, or with MiM. I regard each of these tasks as approximately equally difficult. I could hack SRA to use larger numbers, even pre generate them on the server, but that would break compatibility with existing SRA implementations (which do exist, believe it or not). To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
kernel symbol `gd_curpcb' not found
I have tried to debug a kernel by simulating a panic without success. I have read the handbook and searched the mailinglist. I even tried not to strip the debug kernel at all. Still I get the above message and I do not know how to go on. The following are the commands that I used: now5# gdb -k GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. .. This GDB was configured as i386-unknown-freebsd. (kgdb) symbol-file /kernel Reading symbols from /kernel...done. (kgdb) exec-file kernel.6 (kgdb) core-file vmcore.6 IdlePTD 3600384 kernel symbol `gd_curpcb' not found. (kgdb) where No stack. Thanks for any help. -- Zhihui Zhang. Please visit http://www.freebsd.org -- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: BSD XFS Port BSD VFS Rewrite
On Mon, 16 Aug 1999, Terry Lambert wrote: For an interesting take on all this visit www.mipsabi.org Uh, that site is dead, as of the end of this month. See the first link (announcement). Precisely my point ... ron To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Raw Packet code containing security bits
I wonder if anyone here could perhaps of be assistance, Im currently
playing with implementing certain things in trusted bsd to do with ip
security classes and how the system responds to security bits, and
implementing certain things the stack etc. However my first piece of test
code playing with raw packets to test how things respond to packets with
the security bit set, doesnt seem to want to work. This code compiles
fine, however when I try and run it it says invalid argument when it tries
to send the packet. If anyone could give me any insight as to why this
code doesnt run properly, it would be much appreciated, and would
certainly help me in my efforts to continue expanding trusted bsd.
Ive included the code below..
Thanks
Andrew
--- Code starts here ---
#include stdlib.h
#include stdio.h
#include sys/types.h
#include sys/socket.h
#include netinet/in.h
#include arpa/inet.h
#include netinet/in_systm.h
#include netinet/ip.h
#include unistd.h
#include string.h
#include time.h
#include netinet/udp.h
#define IPVERSION 4 /* Define the IP Version (always 4, until we go
ipv6) */
#define DEFAULT_TTL 60 /* Define the default Time to Live as 60 */
#define DESTPORT 1700
struct pseudohdr {
struct in_addr source_address;
struct in_addr dest_address;
u_char place_holder;
u_char proto;
u_short length;
} pseudohdr;
u_short in_chksum(u_short *addr, int len) {
register int nleft = len;
register u_short *w = addr;
register int sum = 0;
u_short answer = 0;
while (nleft 1) {
sum += *w++;
nleft -= 2;
}
if (nleft == 1) {
*(u_char *)(answer) = *(u_char *)w;
sum += answer;
}
sum = (sum 16) + (sum 0x);
sum += (sum 16);
answer = ~sum;
return(answer);
};
u_short trans_check(u_char proto, char *packet, int length,
struct in_addr source_address, struct in_addr
dest_address)
{
char *pseudo_packet;
u_short answer;
pseudohdr.proto = proto;
pseudohdr.length = htons(length);
pseudohdr.place_holder = 0;
pseudohdr.source_address = source_address;
pseudohdr.dest_address = dest_address;
if((pseudo_packet = malloc(sizeof(struct pseudohdr) + length)) == NULL)
{
perror(malloc);
exit(-1);
}
memcpy(pseudo_packet, pseudohdr, sizeof(pseudohdr));
memcpy((pseudo_packet + sizeof(pseudo_packet)), packet, length);
answer = (u_short)in_chksum((u_short *)pseudo_packet, (length +
sizeof(pseudohdr)));
free(pseudo_packet);
return answer;
};
void ipgenerate(char *packet, u_char protocol, struct in_addr saddr,
struct in_addr daddr, u_short length)
{
struct ip *iphead;
iphead = (struct ip *)packet;
memset((char *)iphead, '\0', sizeof(struct ip));
iphead-ip_hl = 5; /* Define the ip header length
as 6, this is standard packet
+ security class option,
counted in 32 bit words */
iphead-ip_v = IPVERSION; /* Set the ip version to 4 as
its ipv4 not ipv6 */
iphead-ip_len = htons(length); /* Set the packet length in
network byte order */
iphead-ip_id = htons(getpid());/* Set the packet id to the
process id */
iphead-ip_ttl = DEFAULT_TTL; /* Set the time to live to the
default defined (60 seconds) */
iphead-ip_p = protocol;/* Set the protocol
(tcp/udp/icmp) */
iphead-ip_src = saddr; /* Set the source address */
iphead-ip_dst = daddr; /* Set the destination address
*/
iphead-ip_sum = (u_short)in_chksum((u_short *)iphead,
sizeof(struct ip)); /* Set the checksum */
printf(sizeof: %d\n,sizeof(struct ip));
};
void addsecure(char *packet)
{
char *pack;
pack = (char *)packet+sizeof(struct ip);
pack[0] = 0x82; /* We want a security option that is copied on
all fragmentation */
pack[1] = 0xB;
pack[2] = 0x6B; /* We class this packet as top secret */
pack[3] = 0xC5;
pack[4] = 0;/* Packet is non compartmentalized */
pack[5] = 0;
pack[6] = 0;/* More security crap from DIAM 65-19 */
pack[7] = 0;
pack[8] = 0;/* Still more crap leave this 0 */
pack[9] = 0;
pack[10] = 0;
pack[11] = 0; /* Terminate the packet options */
/* Packet data now starts at (char *)packet+sizeof(struct ip)+12 */
};
void addudphead(char *packet, u_short sport, u_short dport, u_short length)
{
Re: Filesystem question...
Actually, i'd expect far fewer problems for the private mounts than for user mounts which modify the name space for all processes ... The concept of private namespaces does not exist on FreeBSD. It would require a modification of the lookup mechanism, and, potentially, a seperation of credentials from the process into a session manager. This is actually the problem at issue in an SMBFS implementation, and for which the Linux guys punted: the credential in SMB is per connection, not per user. There is some newer stuff in LANMan to deal with this inter-NT, and SAMBA incorporates this, but session ID's are not supported over a single VC by all LANMan servers. NetWare has the same problem, FWIW, as does NUC (a client FS for NetWare). Terry Lambert te...@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Whither makefiles for src/crypto/telnet/* ?
Cool, another non-exportable system available to US users only. :-) Yeah... isn't it time you Yanks got together and stormed that Trade Dept? I mean, if you can get excited over a few wooden crates containing tea... ;-) ;-) Pound for pound (no pun intended), Tea was much more expensive than gold at the time. That's why all real antique tea cozy's have functional locks. Terry Lambert te...@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: BSD XFS Port BSD VFS Rewrite
On Sat, 14 Aug 1999, Terry Lambert wrote: I am currently conducting a thorough study of the VFS subsystem in preparation for an all-out effort to port SGI's XFS filesystem to FreeBSD 4.x at such time as SGI gives up the code. Matt Dillon has written in hackers- that the VFS subsystem is presently not well understood by any of the active kernel code contributers and that it will be rewritten later this year. This is obviously of great concern to me in this port. It is of great concern to me that a rewrite, apparently because of non-understanding, is taking place at all. That concerns me too. Many aspects of the 4.4 vnode interface were there for specific reasons. Even if they were hack solutions, to re-write them because of a lack of understanding is dangerous as the new code will likely run into the same problems as before. :-) Also, it behooves all the *BSD's to not get too divergent. Sharing code between us all helps all. Given that I'm working on the kernel side of a data migration file system using NetBSD, I can assure you there are things which FreeBSD would get access to more easily the more-similar the two VFS interface are. :-) I would suggest that anyone planning on this rewrite should talk, in depth, with John Heidemann prior to engaging in such activity. John is very approachable, and is a deep thinker. Any rewrite that does not meet his original design goals for his stacking architecture is, I think, a Very Bad Idea(tm). I greatly appreciate all assistance in answering the following questions: 1) What are the perceived problems with the current VFS? 2) What options are available to us as remedies? 3) To what extent will existing FS code require revision in order to be useful after the rewrite? 4) Will Chapters 6,7,8 9 of The Design and Implementation of the 4.4BSD Operating System still pertain after the rewrite? 5) How important are questions 3 4 in the design of the new VFS? I believe that the VFS is conceptually sound and that the existing semantics should be strictly retained in the new code. Any new functionality should be added in the form of entirely new kernel routines and system calls, or possibly by such means as converting the existing routines to the vararg format etc. Here some of the problems I'm aware of, and my suggested remedies: 1.The interface is not reflexive, with regard to cn_pnbuf. Specifically, path buffers are allocated by the caller, but not freed by the caller, and various routines in each FS implementation are expected to deal with this. Each FS duplicates code, and such duplication is subject to error. Not to mention that it makes your kernel fat. Yep, that's not good. 2.Advisory locks are hung off private backing objects. Advisory locks are passed into VOP_ADVLOCK in each FS instance, and then each FS applies this by hanging the locks off a list on a private backing object. For FFS, this is the in core inode. A more correct approach would be to hang the lock off the vnode. This effectively obviates the need for having a VOP_ADVLOCK at all, except for the NFS client FS, which will need to propagate lock requests across the net. The most efficient mechanism for this would be to institute a pass/fail response for VOP_ADVLOCK calls, with a default of pass, and an actual implementation of the operand only in the NFS client FS. I agree that it's better for all fs's to share this functionality as much as possible. I'd vote againsts your implimentation suggestion for VOP_ADVLOCK on an efficiency concern. If we actually make a VOP call, that should be the end of the story. I.e either add a vnode flag to indicate pas/fail-ness, or add a genfs/std call to handle the problem. I'd actually vote for the latter. Hang the byte-range locking off of the vnode, and add a genfs_advlock() or vop_stdadvlock() routine (depending on OS flavor) to handle the call. That way all fs's that can share code, and the callers need only call VO_ADVLOCK() - no other logic. NetBSD actually needs this to get unionfs to work. Do you want to talk privately about it? Again, each FS must duplicate the advisory locking code, at present, and such duplication is subject to error. Agreed. 3.Object locks are implemented locally in many FS's. The VOP_LOCK interface is implemented via vop_stdlock() calls in many FS's. This is done using the vfs_default mechanism. In other FS's, it's implemented locally. The intent of the VOP_LOCK mechanism being implemented as a VOP at all was to allow it to be proxied to another machine over a network, using the original Heidemann design. This is also the reason for the use of descriptors for all VOP arguments, since they can be opaquely proxied
Re: Filesystem question...
On Mon, Aug 16, 1999 at 08:22:02PM +, Terry Lambert wrote: This is actually the problem at issue in an SMBFS implementation, and for which the Linux guys punted: the credential in SMB is per connection, not per user. Per connection creds suck performance wise (=I haven't seen an implementation which didn't). But, oh well.. There is some newer stuff in LANMan to deal with this inter-NT, and SAMBA incorporates this, but session ID's are not supported over a single VC by all LANMan servers. NetWare has the same problem, FWIW, as does NUC (a client FS for NetWare). At the risk of being flamed to death, you could use krb5 for that purpose.. Perhaps time to revive AFS? Seems that some of the issues here were solved in Transarc's/IBM's AFS that I used a while back (ok, it was a pain to run sometimes, but there's nothing per se that says you couldn't unbreak those things -- it's an implementation and availability of tools issue more than anything). Cheerios, Chris -- Christian Kuhtz, Sr. Network ArchitectBellSouth Corporation c...@adsu.bellsouth.com -wk, c...@gnu.org -hmAdvanced Data Services Affiliation given for identification, not representation. Atlanta, GA, U.S. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: BSD XFS Port BSD VFS Rewrite
2. Advisory locks are hung off private backing objects. Advisory locks are passed into VOP_ADVLOCK in each FS instance, and then each FS applies this by hanging the locks off a list on a private backing object. For FFS, this is the in core inode. A more correct approach would be to hang the lock off the vnode. This effectively obviates the need for having a VOP_ADVLOCK at all, except for the NFS client FS, which will need to propagate lock requests across the net. The most efficient mechanism for this would be to institute a pass/fail response for VOP_ADVLOCK calls, with a default of pass, and an actual implementation of the operand only in the NFS client FS. I agree that it's better for all fs's to share this functionality as much as possible. I'd vote againsts your implimentation suggestion for VOP_ADVLOCK on an efficiency concern. If we actually make a VOP call, that should be the end of the story. I.e either add a vnode flag to indicate pas/fail-ness, or add a genfs/std call to handle the problem. I'd actually vote for the latter. Hang the byte-range locking off of the vnode, and add a genfs_advlock() or vop_stdadvlock() routine (depending on OS flavor) to handle the call. That way all fs's that can share code, and the callers need only call VO_ADVLOCK() - no other logic. OK. Here's the problem with that: NFS client locks in a stacked FS on top the the NFS client FS. Specifically, you need to seperate the idea of asserting a lock against the local vnode, asserting the lock via NFS locking, and coelescing the local lock list, after both have succeeded, or reverting the local assertion, should the remote assertion fail. This is particularly important for transformative layers, specifically cryptographic or compressing layers. A similar issue exists for character sets, e.g. a Unicode enabled OS NFS mounting via NFS an ISO 8859-1 filesystem, and having to do the directory (de)bloat on the fly. NetBSD actually needs this to get unionfs to work. Do you want to talk privately about it? If you want. FreeBSD needs it for unionfs and nullfs, so it's something that would be worth airing. I think you could say that no locking routine was an approval of the uuper level lock. This lets you bail on all FS's except NFS, where you have to deal with the approve/reject from the remote host. The problem with this on FreeBSD is the VFS_default stuff, which puts a non-NULL interface on all FS's for all VOP's. 3. Object locks are implemented locally in many FS's. The VOP_LOCK interface is implemented via vop_stdlock() calls in many FS's. This is done using the vfs_default mechanism. In other FS's, it's implemented locally. The intent of the VOP_LOCK mechanism being implemented as a VOP at all was to allow it to be proxied to another machine over a network, using the original Heidemann design. This is also the reason for the use of descriptors for all VOP arguments, since they can be opaquely proxied to another machine via a general mechanism. Unlike NFS based network filesystems, this would allow you to add VOP's to both machines, without having to teach the transport about the new VOP for it to be usable remotely. Just for a point of comparison, I recently got almost all the NetBSD fs's to use common code. After our -Lite2 merge, all fs's were either calling the lock manager, or using genfs_nolock() (a version for non-locking fs's). Now there's a struct lock * and struct lock in struct vnode. The fs exports its locking behavior via the struct lock *. For most fs's, the struct lock * points to the struct lock, and genfs_lock() feeds that to the lock manager. But we've kept the ability to do something different (like call over the network) alive. If the struct lock * is NULL, you have to call VOP_LOCK on that fs. Note that this difference only matters for layered fs's - everything else should be calling VOP_LOCK() and letting the dispatch code figure out the right thing to do. Yes, this NULL is the same NULL I suggested for advisory locks, above. FreeBSD has moved to more common code, but it's all call-down based because of the vfs_default stuff again. 5. The idea of root vs. non-root mounts is inherently bad. Right now, there are several operations, all wrapped into a single mount entry point. This is actually a partial transition to a more cannonically correct implemetnation. The reason for the root vs. non-root knowledge in the code has to do with several logical operations: 1) Mounting the filesystem; that is, getting the vnode for the device to be mounted, and doing any FS specific operations necessary to cause the correct in-core context to be established. 2) Covering the vnode at the mount
Re: Filesystem question...
On Mon, 16 Aug 1999, Terry Lambert wrote: The concept of private namespaces does not exist on FreeBSD. It would require a modification of the lookup mechanism, and, potentially, a seperation of credentials from the process into a session manager. Yeah but you can fake it pretty well without such mods. I've done it once already on linux and the same techniques I used would work on freebsd. But I can't get anyone interested :-( ron To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Filesystem question...
On Mon, 16 Aug 1999, Terry Lambert wrote: The concept of private namespaces does not exist on FreeBSD. It would require a modification of the lookup mechanism, and, potentially, a seperation of credentials from the process into a session manager. Yeah but you can fake it pretty well without such mods. I've done it once already on linux and the same techniques I used would work on freebsd. But I can't get anyone interested :-( Uh, we're all interested; where's the code? -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msm...@freebsd.org \\-- Joseph Merrick \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Filesystem question...
On Mon, 16 Aug 1999, Mike Smith wrote: But I can't get anyone interested :-( Uh, we're all interested; where's the code? v9fs is the first piece. The servers are done. But I'm mostly out of the freebsd hacking business at this point (except for maybe via drivers) so I need some help to get the rest of it plugged into freebsd. I'm no longer supported to do this kind of thing. ron To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Saving system image to disk (NOT on a laptop)
Hi, To all you low-level kernel and bootloader hackers: what would it take to save and restore a running system image (presumably from dedicated raw partition) so that the system would continue where it left before reboot? It doesn't sound that difficult to me - after all, laptops somehow do it - but I know too little low-level stuff to try implementing it myself... Any comments? Some code? ;-) Andrzej Bialecki // ab...@webgiro.com WebGiro AB, Sweden (http://www.webgiro.com) // --- // -- FreeBSD: The Power to Serve. http://www.freebsd.org // --- Small Embedded FreeBSD: http://www.freebsd.org/~picobsd/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Saving system image to disk (NOT on a laptop)
Hi, To all you low-level kernel and bootloader hackers: what would it take to save and restore a running system image (presumably from dedicated raw partition) so that the system would continue where it left before reboot? It doesn't sound that difficult to me - after all, laptops somehow do it - but I know too little low-level stuff to try implementing it myself... It's quite difficult, in that it requires intimate low-level knowledge of the hardware in order to save/restore its state correctly. In the case of laptops it's much easier because the hardware can't be changed under the image, and the BIOS knows all about the hardware. To do it right in the generic case, you'd virtually have to go through the entire boot process again. It might make more sense to try an alternative arrangement whereby you paged _everything_ out to swap, then saved the entire kernel data and bss segments somewhere. You'd have fun at the restore's cutover point though, and any stateful hardware would still be a bitch to deal with. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msm...@freebsd.org \\-- Joseph Merrick \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
vnc on nat-proxy/firewall
I need to remote-control an NT behind a unix-box running nat-proxy/firewall/gateway. Would it be possible first to connect from the outside to a vnc-server on gateway, then to run vnc-client on the gateway to connect to a vnc-server on the nt? Or is it possible to have a vnc-proxy on the gateway to redirect to the nt? Leif To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Raw Packet code containing security bits
Hello Andrew, When filling your struct ip *iphead, try replacing: iphead-ip_len = htons(length); with: iphead-ip_len = length; or, for portability reasons, you may want to do something like: #ifdef LINUX || OpenBSD21 #define BO(x) htons(x) #else #define BO(x) (x) #endif And, when filling the ip packet length, do a: iphead-ip_len = BO(length); This is a byte-order issue that has often caused confusion for Linux people... /usr/include/machine/endian.h provides some insight... /Bosko. I wonder if anyone here could perhaps of be assistance, Im currently playing with implementing certain things in trusted bsd to do with ip security classes and how the system responds to security bits, and implementing certain things the stack etc. However my first piece of test code playing with raw packets to test how things respond to packets with the security bit set, doesnt seem to want to work. This code compiles fine, however when I try and run it it says invalid argument when it tries to send the packet. If anyone could give me any insight as to why this code doesnt run properly, it would be much appreciated, and would certainly help me in my efforts to continue expanding trusted bsd. Ive included the code below... Thanks Andrew [snipped] - - - . . Bosko Milekic bmile...@dsuper.net http://www.dsuper.net/~bmilekic/ Network Operations - Delphi SuperNet, an Internet Direct company +1.514.281.7500 (vox) / +1.514.281.6599 (fax) / http://www.dsuper.net/ . . - - - To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: [Fwd: [URGENT] CVS problems]
According to Mark Jaffe: CVS is issuing an out of memory message on attempting to checkin a 12MB file. What can I do? There is 300M of swap on the machine, it is running FreeBSD 2.2.8, and CVS says: Concurrent Versions System (CVS) 1.9.26 (client/server) I'll post this to the lists, too. Check the limits for the user running the command (datasize stacksize), both locally and remotely. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #73: Sat Jul 31 15:36:05 CEST 1999 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: BSD XFS Port BSD VFS Rewrite
On Mon, 16 Aug 1999, Terry Lambert wrote: 2.Advisory locks are hung off private backing objects. I'd vote againsts your implimentation suggestion for VOP_ADVLOCK on an efficiency concern. If we actually make a VOP call, that should be the end of the story. I.e either add a vnode flag to indicate pas/fail-ness, or add a genfs/std call to handle the problem. I'd actually vote for the latter. Hang the byte-range locking off of the vnode, and add a genfs_advlock() or vop_stdadvlock() routine (depending on OS flavor) to handle the call. That way all fs's that can share code, and the callers need only call VO_ADVLOCK() - no other logic. OK. Here's the problem with that: NFS client locks in a stacked FS on top the the NFS client FS. Ahh, but it'd be the fs's decision to map genfs_advlock()/vop_stdadvlock() to its vop_advlock_desc entry or not. In this case, NFS wouldn't want to do that. Though it would mean growing the fs footprint. Specifically, you need to seperate the idea of asserting a lock against the local vnode, asserting the lock via NFS locking, and coelescing the local lock list, after both have succeeded, or reverting the local assertion, should the remote assertion fail. Right. But my thought was that you'd be calling an NFS routine, so it could do the right thing. NetBSD actually needs this to get unionfs to work. Do you want to talk privately about it? If you want. FreeBSD needs it for unionfs and nullfs, so it's something that would be worth airing. I think you could say that no locking routine was an approval of the uuper level lock. This lets you bail on all FS's except NFS, where you have to deal with the approve/reject from the remote host. The problem with this on FreeBSD is the VFS_default stuff, which puts a non-NULL interface on all FS's for all VOP's. I'm not familiar with the VFS_default stuff. All the vop_default_desc routines in NetBSD point to error routines. Yes, this NULL is the same NULL I suggested for advisory locks, above. I'm not sure. The struct lock * is only used by layered filesystems, so they can keep track both of the underlying vnode lock, and if needed their own vnode lock. For advisory locks, would we want to keep track both of locks on our layer and the layer below? Don't we want either one or the other? i.e. layers bypass to the one below, or deal with it all themselves. 5.The idea of root vs. non-root mounts is inherently bad. You forgot: 5) Update export lists If you call the mount routine with no device name (args.fspec == 0) and with MNT_UPDATE, you get routed to the vfs_export routine This must be the job of the upper level code, so that there is a single control point for export information, instead of spreading it throughout ead FS's mount entry point. I agree it should be detangled, but think it should remain the fs's job to choose to call vfs_export. Otherwise an fs can't impliment its own export policies. :-) I thought it was? Admitedly the only reference code I have is the ntfs code in the NetBSD kernel. But given how full of #ifdef (__FreeBSD__)'s it is, I thought it'd be an ok reference. No. We've lost the context, but what I was trying to say was that I thought the marking-the-vnode-as-mounted-on bit was done in the mount syscall at present. At least that's what http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/vfs_syscalls.c?rev=1.130 seems to be doing. Basically, what you would have is the equivalent of a variable length mounted volume table, from which mappings (and exports, based on the mappings) are externalized into the namespace. Ahh, sounds like you're talking about a new formalism.. Right. It should just have a mount entry point, and the rest of the stuff moves to higher level code, called by the mount system call, and the mountroot stuff during boot, to externalize the root volume at the top of the hierarchy. An ideal world would mount a / that had a /dev under it, and then do transparent mounts over top of that. That would be quite a different place than we have now. ;-) The conversion of the root device into a vnode pointer, or a path to a device into a vnode pointer, is the job of upper level code -- specifically, the mount system call, and the common code for booting. My one concern about this is you've assumed that the user is mounting a device onto a filesystem. No. Vnoide, not bdevvp. The bdevvp stuff is for the boot time stuff in the upper level code, and only applies to the root volume. Maybe I mis-parsed. I thought you were talking about parsing the first mount option (in mount /dev/disk there, the /dev/disk option) into a vnode. The concern below is that different fs's have different ideas as to what that node should be. Some want it a device node which no one else is using (most leaf fs's), while some others want a
Re: [Fwd: [URGENT] CVS problems]
Mark Jaffe wrote: CVS is issuing an out of memory message on attempting to checkin a 12MB file. What can I do? There is 300M of swap on the machine, it is running FreeBSD 2.2.8, and CVS says: Concurrent Versions System (CVS) 1.9.26 (client/server) Anyone help? How big is the history file size (compared to the processes' max allowed data size)? CVS has a number of brain-damanged areas; one in particular is that CVS reads the *ENTIRE* history file into memory when doing stuff ... and it's doing so simply to scan the history file line-by-line -- Darryl Okahata darr...@sr.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Hewlett-Packard, or of the little green men that have been following him all day. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Using legacy sysinstall to upgrade live system
On Sat, Aug 14, 1999 at 12:29:42PM +0200, Sheldon Hearn wrote: On Fri, 13 Aug 1999 17:51:10 MST, dannyman wrote: Uhmmm, what if we don't have a floppy drive? Then you probably have a CDROM drive or a network interface, both of which can be used to get sysinstall onto your machine. :-) The point of it is, it's easy enough to download the floppies, but it's really hard to boot a system off an .flp image. :p Or, the real point of it is, that aside from make world from source there is no good way to update an existing system without doing something lame like having to boot ... off ... a floppy ... uncompressing kernel ... please wait ... But, on to my original question, has anybody been looking at a more user friendly upgrade the darn thing *REAL EASY* kind of setup? maybe invoke a networked pkg_add to run the latest sysinstall w dependencies? -dman -- dannyman - http://www.dannyland.org/~dannyman/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Using legacy sysinstall to upgrade live system
dannyman wrote: The point of it is, it's easy enough to download the floppies, but it's really hard to boot a system off an .flp image. :p 1. boot single-user 2. dd if=/some/dir/boot.flp of=/dev/da0s1b 3. reboot 4. When boot1 gives you the 5-second paused baton, press any key 5. enter da(0,b) at the Boot: prompt Us FreeBSD people can pretend we can do miniroot installs too :-) [ admittedly, I haven't tried this since before the new boot blocks were committed, but it worked perfectly last year... ] - mark Mark Newton Email: new...@internode.com.au (W) Network Engineer Email: new...@atdot.dotat.org (H) Internode Systems Pty Ltd Desk: +61-8-82232999 Network Man - Anagram of Mark Newton Mobile: +61-416-202-223 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: vnc on nat-proxy/firewall
vnc is cool, but also check out back-orafice (not sure where you get it but the new one can take over NT as well as W95) On Tue, 17 Aug 1999, Leif Neland wrote: I need to remote-control an NT behind a unix-box running nat-proxy/firewall/gateway. Would it be possible first to connect from the outside to a vnc-server on gateway, then to run vnc-client on the gateway to connect to a vnc-server on the nt? Or is it possible to have a vnc-proxy on the gateway to redirect to the nt? Leif To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: vnc on nat-proxy/firewall
On 17-Aug-99 Julian Elischer wrote: vnc is cool, but also check out back-orafice (not sure where you get it but the new one can take over NT as well as W95) BO2K does NT (much to MS's chagrin)... --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum pgpkf2YCdExeH.pgp Description: PGP signature
Re: BSD XFS Port BSD VFS Rewrite
2. Advisory locks are hung off private backing objects. I'd vote againsts your implimentation suggestion for VOP_ADVLOCK on an efficiency concern. If we actually make a VOP call, that should be the end of the story. I.e either add a vnode flag to indicate pas/fail-ness, or add a genfs/std call to handle the problem. I'd actually vote for the latter. Hang the byte-range locking off of the vnode, and add a genfs_advlock() or vop_stdadvlock() routine (depending on OS flavor) to handle the call. That way all fs's that can share code, and the callers need only call VO_ADVLOCK() - no other logic. OK. Here's the problem with that: NFS client locks in a stacked FS on top the the NFS client FS. Ahh, but it'd be the fs's decision to map genfs_advlock()/vop_stdadvlock() to its vop_advlock_desc entry or not. In this case, NFS wouldn't want to do that. Though it would mean growing the fs footprint. Nope; that's not really the problem. The problem is if I have two local processes that get into a race in order to obtain a remote lock. Because the remote lock is not asserted, there's no way to ensure that the order of service for the request is the same as the order of request -- consider cooperating programs, like sendmail and pine or elm (or whatever). The only way to resolve this is to ensure that the cooperating programs on the same system are lockstepped: at the client. The only way to do this is to assert the lock locally, then remotely, if the local assertion succeeds. In the case of our cooperating local processes, this resolves the race condition (depending on F_SETLCK/F_SETLCKW, they behave as if the locks were local. Which is what you want. Specifically, you need to seperate the idea of asserting a lock against the local vnode, asserting the lock via NFS locking, and coelescing the local lock list, after both have succeeded, or reverting the local assertion, should the remote assertion fail. Right. But my thought was that you'd be calling an NFS routine, so it could do the right thing. The problem is that the local lock doesn't belong to NFS. Even if it did (I think this would be an error for a remotely mounted whiteout in a translucent local FS), the problem is that in doing the local assertion, you will intrinsically coeelesce locks. Now if the lock mode you are requesting overlaps a previous lock, and the modes are not exactly the same, there's no way to back out the local promotion or demotion without a coelesce. This doesn't resolve the most complex cases you could contrive, with multiple stacking layers that don't support a distributed coherency protocol for locks for two or more players, but it handles the local vs. NFS issues acceptably. NetBSD actually needs this to get unionfs to work. Do you want to talk privately about it? If you want. FreeBSD needs it for unionfs and nullfs, so it's something that would be worth airing. I think you could say that no locking routine was an approval of the uuper level lock. This lets you bail on all FS's except NFS, where you have to deal with the approve/reject from the remote host. The problem with this on FreeBSD is the VFS_default stuff, which puts a non-NULL interface on all FS's for all VOP's. I'm not familiar with the VFS_default stuff. All the vop_default_desc routines in NetBSD point to error routines. In FreeBSD, they now point to default routines that are *not* error routines. This is the problem. I admit the change was very well intentioned, since it made the code a hell of a lot more readable, but choosing between readable and additional function, I take function over form (I think the way I would have fixed the readability is by making the operations that result in the descriptor set for a mounted FS instance be both discrete, and named for their specific function). Yes, this NULL is the same NULL I suggested for advisory locks, above. I'm not sure. The struct lock * is only used by layered filesystems, so they can keep track both of the underlying vnode lock, and if needed their own vnode lock. For advisory locks, would we want to keep track both of locks on our layer and the layer below? Don't we want either one or the other? i.e. layers bypass to the one below, or deal with it all themselves. I think you want the lock on the intermediate layer: basically, on every vnode that has data associated with it that is unique to a layer. Let's not forget, also, that you can expose a layer into the namespace in one place, and expose it covered under another layer, at another. If you locked down to the backing object, then the only issue you would be left with is one or more intermediate backing objects. For a layer with an intermediate backing object, I'm prepared to declare it special, and proxy the operation down to any inferior backing object (e.g. a union FS that adds files from two FS's together, rather than just
How much memory (max) will FreeBSD use?
I've looked at http://www.freebsd.org/FAQ/FAQ51.html, but the answer seems to be lacking... On a stock system (3.2 and 4.0), how much RAM will a system be able to use? Will a stock system use all 4GB? Thanks, -- Stephen J. Roznowski(s...@home.net) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Kerberos 5 integration.
Who were the parties that were heading up the Kerberos 5 integration? I have questions. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | win...@jurai.net | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Using legacy sysinstall to upgrade live system
On Mon, 16 Aug 1999 17:48:22 MST, dannyman wrote: The point of it is, it's easy enough to download the floppies, but it's really hard to boot a system off an .flp image. :p Presumably you saw the posted trick about dd'ing the floppy image to your swap partition and booting off _that_? :-) But, on to my original question, has anybody been looking at a more user friendly upgrade the darn thing *REAL EASY* kind of setup? maybe invoke a networked pkg_add to run the latest sysinstall w dependencies? Your original question? I started this thread. ;-) The best answer someone who is neither omniscient nor omnipresent can give you is I expect I'd be surprised to find that anybody was working on such a thing. Assume that further silence on the issue confirms that feeling. I've seen lots of people come up with ideas that they felt were good and worthy of lots of argument, but the ideas always seem to be all talk(1) and no diff(1). ;-) Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
