Re: Whither makefiles for src/crypto/telnet/* ?
If you really want to work on an encrypted telnet, check out The Stanford SRP Authentication Project (http://srp.stanford.edu/srp/). I'd love to see SRP integrated into the FreeBSD telnet/telnetd. Dave -- Dave Walton Webmaster, Postmaster Nordic Entertainment Worldwide wal...@nordicdms.com http://www.nordicdms.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/* ?
If you really want to work on an encrypted telnet, check out The Stanford SRP Authentication Project (http://srp.stanford.edu/srp/). I'd love to see SRP integrated into the FreeBSD telnet/telnetd. Dave -- Dave Walton Webmaster, Postmaster Nordic Entertainment Worldwide [EMAIL PROTECTED] http://www.nordicdms.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 19:49:10 -0400 (EDT) > James Howard wrote: > > > I did, they have a feedback form I filled out yesterday. I mentioned that > > and that if they dual licensed the code, it could be used by the entire > > free software community, not just the hip Linux crowd and also mentioned > > that a great many in the BSD community are interested in the code. Of > > course, I phrased it more professionally. > > The thing is, they don't have to dual license it for it to be usable > by both Linux and BSD! > > Including BSD-licensed code in Linux is prefectly legitimate, and in > fact, there is already such code in Linux now. > > So, if they were to simply put a BSD license on the code, then everyone > would be happy, and there wouldn't be any of the dual-license confusion. It doesn't work like that; once it's been distributed with Linux it's no longer BSD-licensed, it's GPLed. They would still be unable to recover post-viral changes and reuse them in their own XFS product. -- \\ 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: host byte order in networkin routines?!?
David E. Cross writes: > A friend writing some portable network tunneling software ran into an > interesting thing... when you specify "IP_HDRINCL" with SOCK_RAW, and > IPPROTO_RAW you need to construct the outgoing packet in host byte order. > > This seems wonderfully inconsistent with all of the other socket based > networking interface in FreeBSD, and it is also inconsistent with other > Operating Systems. Would it be possible to get this changed? I can provide > diffs if need be. I suspect most people agree it needs to be changed, but the problem is (as usual) all the legacy code that would break. Maybe if you had a temporary check in the kernel for backwards packets that would cause a core dump.. ? Ugh. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.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 19:49:10 -0400 (EDT) > James Howard <[EMAIL PROTECTED]> wrote: > > > I did, they have a feedback form I filled out yesterday. I mentioned that > > and that if they dual licensed the code, it could be used by the entire > > free software community, not just the hip Linux crowd and also mentioned > > that a great many in the BSD community are interested in the code. Of > > course, I phrased it more professionally. > > The thing is, they don't have to dual license it for it to be usable > by both Linux and BSD! > > Including BSD-licensed code in Linux is prefectly legitimate, and in > fact, there is already such code in Linux now. > > So, if they were to simply put a BSD license on the code, then everyone > would be happy, and there wouldn't be any of the dual-license confusion. It doesn't work like that; once it's been distributed with Linux it's no longer BSD-licensed, it's GPLed. They would still be unable to recover post-viral changes and reuse them in their own XFS product. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ [EMAIL PROTECTED] \\-- Joseph Merrick \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: host byte order in networkin routines?!?
David E. Cross writes: > A friend writing some portable network tunneling software ran into an > interesting thing... when you specify "IP_HDRINCL" with SOCK_RAW, and > IPPROTO_RAW you need to construct the outgoing packet in host byte order. > > This seems wonderfully inconsistent with all of the other socket based > networking interface in FreeBSD, and it is also inconsistent with other > Operating Systems. Would it be possible to get this changed? I can provide > diffs if need be. I suspect most people agree it needs to be changed, but the problem is (as usual) all the legacy code that would break. Maybe if you had a temporary check in the kernel for backwards packets that would cause a core dump.. ? Ugh. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.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 19:37:42 -0700 (PDT) Kris Kennaway wrote: > > So, if they were to simply put a BSD license on the code, then everyone > > would be happy, and there wouldn't be any of the dual-license confusion. > > Unfortunately, by BSD-licensing the XFS code, SGI would be allowing their > direct economic competitors (Sun, Microsoft, etc) to add the technology to > their products in a closed, binary form, for free. Precisely why asking them to do a dual-license is pointless. Not only would it give direct economic competitors[*] this capability, but it would also confuse everyone else. [*] One might argue that SGI no longer has any direct economic competitors, since their machines are too expensive, too unreliable, and no one in their right mind would buy them since the ship is sinking so fast. -- Jason R. Thorpe To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
> > Dan Moschuk wrote: > > > > Does anyone have any issues with merging the new bind resolver API into > > libc? > > Well, Terry does, though I don't quite recall his reasoning. :-) > Notice, he objects the way FreeBSD is today, with the bind resolver > API inside libc. I object because it perpetuates a situation which has made it take this long to get the issue addressed. I also object because BIND 9 is currently in the works, and there is talk of replacing the records with A6 records in the DNSEXT working group. The resolver should be in a seperate library to facilitate speedy integration of future releases, and because its designers put it in a seperate library. The correct way to get historical BSD behaviour, i.e. linking libc gives you the resolver, is to take advantage of ELF, and link the libc against the libresolver, and thus incorporate it by reference (if this doesn't work in FreeBSD, it should; I haven't checked). Of course, my ideal world would update all of the Makefiles for all of the network utilities (including the ports) to know about libresolver explicitly, but that's unlikely to come to pass. 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 Fri, 13 Aug 1999, Jason Thorpe wrote: > > I did, they have a feedback form I filled out yesterday. I mentioned that > > and that if they dual licensed the code, it could be used by the entire > > free software community, not just the hip Linux crowd and also mentioned > > that a great many in the BSD community are interested in the code. Of > > course, I phrased it more professionally. > > The thing is, they don't have to dual license it for it to be usable > by both Linux and BSD! > > Including BSD-licensed code in Linux is prefectly legitimate, and in > fact, there is already such code in Linux now. > > So, if they were to simply put a BSD license on the code, then everyone > would be happy, and there wouldn't be any of the dual-license confusion. Unfortunately, by BSD-licensing the XFS code, SGI would be allowing their direct economic competitors (Sun, Microsoft, etc) to add the technology to their products in a closed, binary form, for free. I have no illusions that SGI is releasing their code for the good of mankind; they're doing it to try and prop up ailing market-share by attaching themselves to the current rising star of the OS world. BSD-licensing their code would give them no economic benefit since it's free for all takers, except perhaps the rosy glow of being open source friendly and generous for giving away their IP. Having made the strategic decision to "go linux" they now perceive they have an advantage over their competitors which is furthered by their use of the GPL to prevent their competitors, who are not comfortable with GPLing their technology to follow suit. Of course, the question is whether SGI will actually benefit from the move. I'd be inclined to doubt it: the Linux hackers are smart - given a mostly working XFS (enough to fulfil SGI's "commitment") there's not going to be much time before SGI aren't needed to support the integration, and the two camps could quite easily part ways. On the other hand, the tactic could be to try and woo the Linux crowd into buying SGI hardware by feeding them trinkets from IRIX, trying to become the hardware platform of choice for Linux servers where IRIX and NT for SGI have failed. 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
On Fri, 13 Aug 1999 19:49:10 -0400 (EDT) James Howard wrote: > I did, they have a feedback form I filled out yesterday. I mentioned that > and that if they dual licensed the code, it could be used by the entire > free software community, not just the hip Linux crowd and also mentioned > that a great many in the BSD community are interested in the code. Of > course, I phrased it more professionally. The thing is, they don't have to dual license it for it to be usable by both Linux and BSD! Including BSD-licensed code in Linux is prefectly legitimate, and in fact, there is already such code in Linux now. So, if they were to simply put a BSD license on the code, then everyone would be happy, and there wouldn't be any of the dual-license confusion. -- Jason R. Thorpe 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 19:37:42 -0700 (PDT) Kris Kennaway <[EMAIL PROTECTED]> wrote: > > So, if they were to simply put a BSD license on the code, then everyone > > would be happy, and there wouldn't be any of the dual-license confusion. > > Unfortunately, by BSD-licensing the XFS code, SGI would be allowing their > direct economic competitors (Sun, Microsoft, etc) to add the technology to > their products in a closed, binary form, for free. Precisely why asking them to do a dual-license is pointless. Not only would it give direct economic competitors[*] this capability, but it would also confuse everyone else. [*] One might argue that SGI no longer has any direct economic competitors, since their machines are too expensive, too unreliable, and no one in their right mind would buy them since the ship is sinking so fast. -- Jason R. Thorpe <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: BSD XFS Port & BSD VFS Rewrite
> >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? > > That is not correct: if SGI only use code that they have full > ownership of in IRIX then they can distribute it separately under the > GPL without releasing the source to the rest of the OS. It's perfectly > valid to distribute software to different people under different > licences (e.g. softupdates, perl). It is correct: they will not be able to incorporate changes, which, by their nature, will be GPL, into a non-GPL product. While it's valid to distribute what you own under two different licenses, it's not going to be possible for them to incorporte improvements to the GPL'ed XFS under any terms other than the GPL, unless they make seperate arrangemenets with the authors. I defy you to grab a single line of the Linux kernel, _at random_, and attribute it to any single author who you could sign a contract with in order to use that line of code commercially. 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
> 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. 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. 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. Again, each FS must duplicate the advisory locking code, at present, and such duplication is subject to error. 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. Like the VOP_ADVLOCK, the need for VOP_LOCK is for proxy purposes, and it, too, should generate a pass/fail response, and be largely implemented in non-filesystem specific higher level code. Again, each FS which duplicates code for this function is subject to duplication errors. 4. The VOP_READIR interface is irrational. The VOP_READDIR interface returns its responses in "host cannonical format" (struct dirent, in sys/dirent.h). Internally, FFS operates on "directory entry blocks" that contain exactly these structures (an intentaional coincidence). The problem with this approach, is that it makes the getdents system call sensitive to file systems for which some of the information returned (e.g. d_fileno, d_reclen, d_type, d_namlen) are synthetic. What this means is that a native file system directory implementation single directory block must be able to fit into the buffer passed to the getdirentries(2) system call, or a directory listing is not a vali
Re: gethostbyaddr() and threads.
> > Dan Moschuk wrote: > > > > Does anyone have any issues with merging the new bind resolver API into > > libc? > > Well, Terry does, though I don't quite recall his reasoning. :-) > Notice, he objects the way FreeBSD is today, with the bind resolver > API inside libc. I object because it perpetuates a situation which has made it take this long to get the issue addressed. I also object because BIND 9 is currently in the works, and there is talk of replacing the records with A6 records in the DNSEXT working group. The resolver should be in a seperate library to facilitate speedy integration of future releases, and because its designers put it in a seperate library. The correct way to get historical BSD behaviour, i.e. linking libc gives you the resolver, is to take advantage of ELF, and link the libc against the libresolver, and thus incorporate it by reference (if this doesn't work in FreeBSD, it should; I haven't checked). Of course, my ideal world would update all of the Makefiles for all of the network utilities (including the ports) to know about libresolver explicitly, but that's unlikely to come to pass. 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 Fri, 13 Aug 1999, Jason Thorpe wrote: > > I did, they have a feedback form I filled out yesterday. I mentioned that > > and that if they dual licensed the code, it could be used by the entire > > free software community, not just the hip Linux crowd and also mentioned > > that a great many in the BSD community are interested in the code. Of > > course, I phrased it more professionally. > > The thing is, they don't have to dual license it for it to be usable > by both Linux and BSD! > > Including BSD-licensed code in Linux is prefectly legitimate, and in > fact, there is already such code in Linux now. > > So, if they were to simply put a BSD license on the code, then everyone > would be happy, and there wouldn't be any of the dual-license confusion. Unfortunately, by BSD-licensing the XFS code, SGI would be allowing their direct economic competitors (Sun, Microsoft, etc) to add the technology to their products in a closed, binary form, for free. I have no illusions that SGI is releasing their code for the good of mankind; they're doing it to try and prop up ailing market-share by attaching themselves to the current rising star of the OS world. BSD-licensing their code would give them no economic benefit since it's free for all takers, except perhaps the rosy glow of being open source friendly and generous for giving away their IP. Having made the strategic decision to "go linux" they now perceive they have an advantage over their competitors which is furthered by their use of the GPL to prevent their competitors, who are not comfortable with GPLing their technology to follow suit. Of course, the question is whether SGI will actually benefit from the move. I'd be inclined to doubt it: the Linux hackers are smart - given a mostly working XFS (enough to fulfil SGI's "commitment") there's not going to be much time before SGI aren't needed to support the integration, and the two camps could quite easily part ways. On the other hand, the tactic could be to try and woo the Linux crowd into buying SGI hardware by feeding them trinkets from IRIX, trying to become the hardware platform of choice for Linux servers where IRIX and NT for SGI have failed. 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
On 13 Aug, Bill Studenmund 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. Now I think people are rushing to conclusions. What I understood from the SGI people I met is that they're planning to make their NT systems to optionally boot to Linux. The other systems will still be running IRIX, which is still under ongoing development. AFAIK, it is not true that IRIX will be replaced by Linux. Then again, this were only two guys from SGI installing our new server... -- Alban Hertroys. http://wit401310.student.utwente.nl == If there is a here-after, then there are much more people dead than alive. Even that much more that the number of living people is insignificant in comparison to the dead ones. Thus it is safe to say that we don't exist. 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 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? That is not correct: if SGI only use code that they have full ownership of in IRIX then they can distribute it separately under the GPL without releasing the source to the rest of the OS. It's perfectly valid to distribute software to different people under different licences (e.g. softupdates, perl). Tony. -- f.a.n.finchd...@dotat.atf...@demon.nete pluribus unix 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 19:49:10 -0400 (EDT) James Howard <[EMAIL PROTECTED]> wrote: > I did, they have a feedback form I filled out yesterday. I mentioned that > and that if they dual licensed the code, it could be used by the entire > free software community, not just the hip Linux crowd and also mentioned > that a great many in the BSD community are interested in the code. Of > course, I phrased it more professionally. The thing is, they don't have to dual license it for it to be usable by both Linux and BSD! Including BSD-licensed code in Linux is prefectly legitimate, and in fact, there is already such code in Linux now. So, if they were to simply put a BSD license on the code, then everyone would be happy, and there wouldn't be any of the dual-license confusion. -- Jason R. Thorpe <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: BSD XFS Port & BSD VFS Rewrite
> >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? > > That is not correct: if SGI only use code that they have full > ownership of in IRIX then they can distribute it separately under the > GPL without releasing the source to the rest of the OS. It's perfectly > valid to distribute software to different people under different > licences (e.g. softupdates, perl). It is correct: they will not be able to incorporate changes, which, by their nature, will be GPL, into a non-GPL product. While it's valid to distribute what you own under two different licenses, it's not going to be possible for them to incorporte improvements to the GPL'ed XFS under any terms other than the GPL, unless they make seperate arrangemenets with the authors. I defy you to grab a single line of the Linux kernel, _at random_, and attribute it to any single author who you could sign a contract with in order to use that line of code commercially. 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
> 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. 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. 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. Again, each FS must duplicate the advisory locking code, at present, and such duplication is subject to error. 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. Like the VOP_ADVLOCK, the need for VOP_LOCK is for proxy purposes, and it, too, should generate a pass/fail response, and be largely implemented in non-filesystem specific higher level code. Again, each FS which duplicates code for this function is subject to duplication errors. 4. The VOP_READIR interface is irrational. The VOP_READDIR interface returns its responses in "host cannonical format" (struct dirent, in sys/dirent.h). Internally, FFS operates on "directory entry blocks" that contain exactly these structures (an intentaional coincidence). The problem with this approach, is that it makes the getdents system call sensitive to file systems for which some of the information returned (e.g. d_fileno, d_reclen, d_type, d_namlen) are synthetic. What this means is that a native file system directory implementation single directory block must be able to fit into the buffer passed to the getdirentries(2) system call, or a directory listing is not a val
Re: Using legacy sysinstall to upgrade live system
On Wed, Aug 11, 1999 at 12:07:41AM -0700, Jordan K. Hubbard wrote: > The use of /stand/sysinstall to do a live upgrade has always been > discouraged, though it's not outright disallowed since I believe in > every man's right to blow his feet off if he really wants to. > > Nonetheless, for the expected installation experience one is > encouraged to boot the desired OS release's installation media and > select an upgrade instead of a new install. Uhmmm, what if we don't have a floppy drive? I suggested my colleague score /stand/sysinstall off one of my 3.2 systems so he could upgrade his 3.1. Has there been though put in to making a net-able upgrade set, maybe you have a sysinstall which pops the new kernel in to place, reboots into sysinstall like a floppy, and then gets ready to upgrade. Maybe we could use an MFS floppy? Might be a fun project to take on ... can one reboot into an MFS partition, or how hard would it be to try a "reboot system into upgrade floppy" without trashing the underlying system, in case the user wanted to bail ... maybe a kernel that chroot's itself into an /upgrade directory? Thoughts? -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: BSD XFS Port & BSD VFS Rewrite
On 13 Aug, Bill Studenmund 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. Now I think people are rushing to conclusions. What I understood from the SGI people I met is that they're planning to make their NT systems to optionally boot to Linux. The other systems will still be running IRIX, which is still under ongoing development. AFAIK, it is not true that IRIX will be replaced by Linux. Then again, this were only two guys from SGI installing our new server... -- Alban Hertroys. http://wit401310.student.utwente.nl == If there is a here-after, then there are much more people dead than alive. Even that much more that the number of living people is insignificant in comparison to the dead ones. Thus it is safe to say that we don't exist. 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: > >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? That is not correct: if SGI only use code that they have full ownership of in IRIX then they can distribute it separately under the GPL without releasing the source to the rest of the OS. It's perfectly valid to distribute software to different people under different licences (e.g. softupdates, perl). Tony. -- f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]e pluribus unix 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 Wed, Aug 11, 1999 at 12:07:41AM -0700, Jordan K. Hubbard wrote: > The use of /stand/sysinstall to do a live upgrade has always been > discouraged, though it's not outright disallowed since I believe in > every man's right to blow his feet off if he really wants to. > > Nonetheless, for the expected installation experience one is > encouraged to boot the desired OS release's installation media and > select an upgrade instead of a new install. Uhmmm, what if we don't have a floppy drive? I suggested my colleague score /stand/sysinstall off one of my 3.2 systems so he could upgrade his 3.1. Has there been though put in to making a net-able upgrade set, maybe you have a sysinstall which pops the new kernel in to place, reboots into sysinstall like a floppy, and then gets ready to upgrade. Maybe we could use an MFS floppy? Might be a fun project to take on ... can one reboot into an MFS partition, or how hard would it be to try a "reboot system into upgrade floppy" without trashing the underlying system, in case the user wanted to bail ... maybe a kernel that chroot's itself into an /upgrade directory? Thoughts? -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: 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? I did, they have a feedback form I filled out yesterday. I mentioned that and that if they dual licensed the code, it could be used by the entire free software community, not just the hip Linux crowd and also mentioned that a great many in the BSD community are interested in the code. Of course, I phrased it more professionally. http://www.sgi.com/cgi-bin/feedback/ Click on XFS. I did that yesterday, no reply so far. Would it be improper to actually call and see if it is possible to contact a real person? Jamie 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. Take care, Bill 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
As I parse the SGI PR-speak, IRIX is to be folded into Linux over time in one massive penguin love-in. This will take place at some point after IRIX has been disencunbered of it's AT&T/Univel/SCO whatever... It really is a good time to be alive. -Original Message- From: Terry Lambert [mailto:tlamb...@primenet.com] Sent: Friday, August 13, 1999 17:49 To: tingu...@plains.nodak.edu Cc: howar...@wam.umd.edu; hack...@freebsd.org Subject: Re: BSD XFS Port & BSD VFS Rewrite > > This is why people should start emailing asking for a dual-license that > > would support incorporation into FreeBSD. > > good luck, the SGI crowd are very Linux-oriented. 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? 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 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 22:49:14 + (GMT) 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? SGI is plummetting to their death; it's not clear that: (a) they care, (b) they'll be around that long for it to make any difference. -- Jason R. Thorpe 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? I did, they have a feedback form I filled out yesterday. I mentioned that and that if they dual licensed the code, it could be used by the entire free software community, not just the hip Linux crowd and also mentioned that a great many in the BSD community are interested in the code. Of course, I phrased it more professionally. http://www.sgi.com/cgi-bin/feedback/ Click on XFS. I did that yesterday, no reply so far. Would it be improper to actually call and see if it is possible to contact a real person? Jamie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: BSD XFS Port & BSD VFS Rewrite
> > > This is why people should start emailing asking for a dual-license that > > would support incorporation into FreeBSD. > > good luck, the SGI crowd are very Linux-oriented. I had some quite promising discussions with several of the SGI folks with regard to getting information on their new intel hardware for the purposes of a port while at LinuxWorld. They don't actually _have_ any hardware documentation (aigh!), but there's a reasonable chance we'll be able to get hold of some useful contacts. One thing at a time. 8) -- \\ 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
> > This is why people should start emailing asking for a dual-license that > > would support incorporation into FreeBSD. > > good luck, the SGI crowd are very Linux-oriented. 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? 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 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. Take care, Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: BSD XFS Port & BSD VFS Rewrite
As I parse the SGI PR-speak, IRIX is to be folded into Linux over time in one massive penguin love-in. This will take place at some point after IRIX has been disencunbered of it's AT&T/Univel/SCO whatever... It really is a good time to be alive. -Original Message- From: Terry Lambert [mailto:[EMAIL PROTECTED]] Sent: Friday, August 13, 1999 17:49 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: BSD XFS Port & BSD VFS Rewrite > > This is why people should start emailing asking for a dual-license that > > would support incorporation into FreeBSD. > > good luck, the SGI crowd are very Linux-oriented. 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? 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 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 22:49:14 + (GMT) Terry Lambert <[EMAIL PROTECTED]> 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? SGI is plummetting to their death; it's not clear that: (a) they care, (b) they'll be around that long for it to make any difference. -- Jason R. Thorpe <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: BSD XFS Port & BSD VFS Rewrite
> > > This is why people should start emailing asking for a dual-license that > > would support incorporation into FreeBSD. > > good luck, the SGI crowd are very Linux-oriented. I had some quite promising discussions with several of the SGI folks with regard to getting information on their new intel hardware for the purposes of a port while at LinuxWorld. They don't actually _have_ any hardware documentation (aigh!), but there's a reasonable chance we'll be able to get hold of some useful contacts. One thing at a time. 8) -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ [EMAIL PROTECTED] \\-- Joseph Merrick \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: BSD XFS Port & BSD VFS Rewrite
> > This is why people should start emailing asking for a dual-license that > > would support incorporation into FreeBSD. > > good luck, the SGI crowd are very Linux-oriented. 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? 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: Threaded X libraries
> I'm attempting to build the X11 libs with the thread safety stuff (I beleive > Linux can already be built like this) and have discovered when linking that > we don't have the getpwnam_r & getpwuid_r functions in out libc_r. Is anyone > planning on adding these? I asked the same question a while ago, and Wes Peters replied saying that the getpwent_r routines would probably require the newlib version of dbm, to ensure proper locking of the database. It also seems that apart from getpwnam_r() and getpwuid_r(), X requires a whole bunch of other reentrant functions, namely: readdir_r(): getgrgid_r(), getgrnam_r(): gethostbyname_r(), gethostbyaddr_r(), getservbyname_r(): strtok_r(): asctime_r(), ctime_r(), localtime_r(), gmtime_r(): getlogin_r(), ttyname_r(): (see xc/include/Xos_r.h) Of these, FreeBSD libc_r only has the *time_r() functions and strtok_r(). Recently there was a discussion about implementing reentrant versions of the resolver functions (get*by*_r()), and someone mentioned that the latest release of BIND already has them thread-safe. It's probably not very hard to implement the remaining functions by replacing the static variables by caller-supplied buffers, and locking access to provide safety from different threads calling the same function at the same time, but unfortunately it still means serialized access. It would be nice to have a _true_ multithreaded implementation, but this is problematic until we lose the big giant lock and evolve some sort of kernel threads or LWPs. Frank P.S. A question for Warner Losh -- what happened to the idea of bringing NetBSD's kernel threads implementation into the kernel? To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: SRA+IDEA Telnet
Kris Kennaway wrote: > > On Fri, 13 Aug 1999, Nick Sayer wrote: > > > I originally obtained SRA code from a University in Germany. I obtained > > my implementation of IDEA from PGP. In fact, I used idea.[ch] and #if > > 0'ed > > out stuff that's not needed. > > Couldn't you work the code so it obtains all its' encryption functions > from an external library, such as the system's libdes? That would let you > export the code, since it doesn't provide any encryption functions itself, > and international people could use the international DES library (for > other encryption algorithms, pick a freely available implmenetation such > as the one from openssl). Alas, the commerce department says that even code that has no cryptography in itself, but that _interfaces_ to a crypto library is unexportable. As an example, I have a hack for pine that interfaces it to Openssl (the pine4+ssl port). That code is unexportable even though it talks to a library that talks to a crypto library. This despite the fact that it is distributed separately from the crypto itself. The same applies to mod_ssl (at least when it is present within the US). You can't pass that around even though it does no encryption by itself at all (the fact that it may be available outside the US doesn't matter either. You still can't export it even if it was originally IMported for it to get here in the first place). Yes, it sucks, and no, I am not making this up. > > I'm not sure what functionality this provides above something like > SSLtelnet (in ports) or ssh, though. Probably much easier for folks to > just use those. The whole point is to have the default system come with something better than plaintext logins that has no administrative overhead. If the default telnet/telnetd (in the DES distribution) had this functionality, it would end up being far more automatic than having to go and build and install ANY alternative in the ports or having to set up either Kerberos or S/key. I use and am a big fan of SSH. But I had to install and configure it. If we're ever going to reach the day when cryptographic security is so routine we don't even think about it, we have to start having it present _by default_. > > Kris smime.p7s Description: S/MIME Cryptographic Signature
Re: Threaded X libraries
> I'm attempting to build the X11 libs with the thread safety stuff (I beleive > Linux can already be built like this) and have discovered when linking that > we don't have the getpwnam_r & getpwuid_r functions in out libc_r. Is anyone > planning on adding these? I asked the same question a while ago, and Wes Peters replied saying that the getpwent_r routines would probably require the newlib version of dbm, to ensure proper locking of the database. It also seems that apart from getpwnam_r() and getpwuid_r(), X requires a whole bunch of other reentrant functions, namely: readdir_r(): getgrgid_r(), getgrnam_r(): gethostbyname_r(), gethostbyaddr_r(), getservbyname_r(): strtok_r(): asctime_r(), ctime_r(), localtime_r(), gmtime_r(): getlogin_r(), ttyname_r(): (see xc/include/Xos_r.h) Of these, FreeBSD libc_r only has the *time_r() functions and strtok_r(). Recently there was a discussion about implementing reentrant versions of the resolver functions (get*by*_r()), and someone mentioned that the latest release of BIND already has them thread-safe. It's probably not very hard to implement the remaining functions by replacing the static variables by caller-supplied buffers, and locking access to provide safety from different threads calling the same function at the same time, but unfortunately it still means serialized access. It would be nice to have a _true_ multithreaded implementation, but this is problematic until we lose the big giant lock and evolve some sort of kernel threads or LWPs. Frank P.S. A question for Warner Losh -- what happened to the idea of bringing NetBSD's kernel threads implementation into the kernel? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Max simultaneous NFS mounts?
:On Thu, Aug 12, 1999 at 11:16:23PM -0700, Gregory Sutter wrote: :> What is the (default) maximum number of simultanous NFS mounts in :> FreeBSD 2.2.8 and 3.2? :> :> I was looking at 3.2 and it appears that 63 is the max, and this is :> tunable with kernel config option NFS_MUIDHASHSIZ. Is this correct? :> What is the maximum possible setting? : :Bleah. Strike that. NFS mounts don't seem to be any different from :normal mounts, so they just get inserted into mountlist, which is a :CIRCLEQ. This means that the only limitation is the amount of :available kernel memory, correct? : :Greg :-- :Gregory S. SutterCole's Law: Thinly sliced cabbage. NFS mounts allocate a dummy minor device number. I believe there is a limitation of 256 there. -Matt Matthew Dillon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: SRA+IDEA Telnet
Kris Kennaway wrote: > > On Fri, 13 Aug 1999, Nick Sayer wrote: > > > I originally obtained SRA code from a University in Germany. I obtained > > my implementation of IDEA from PGP. In fact, I used idea.[ch] and #if > > 0'ed > > out stuff that's not needed. > > Couldn't you work the code so it obtains all its' encryption functions > from an external library, such as the system's libdes? That would let you > export the code, since it doesn't provide any encryption functions itself, > and international people could use the international DES library (for > other encryption algorithms, pick a freely available implmenetation such > as the one from openssl). Alas, the commerce department says that even code that has no cryptography in itself, but that _interfaces_ to a crypto library is unexportable. As an example, I have a hack for pine that interfaces it to Openssl (the pine4+ssl port). That code is unexportable even though it talks to a library that talks to a crypto library. This despite the fact that it is distributed separately from the crypto itself. The same applies to mod_ssl (at least when it is present within the US). You can't pass that around even though it does no encryption by itself at all (the fact that it may be available outside the US doesn't matter either. You still can't export it even if it was originally IMported for it to get here in the first place). Yes, it sucks, and no, I am not making this up. > > I'm not sure what functionality this provides above something like > SSLtelnet (in ports) or ssh, though. Probably much easier for folks to > just use those. The whole point is to have the default system come with something better than plaintext logins that has no administrative overhead. If the default telnet/telnetd (in the DES distribution) had this functionality, it would end up being far more automatic than having to go and build and install ANY alternative in the ports or having to set up either Kerberos or S/key. I use and am a big fan of SSH. But I had to install and configure it. If we're ever going to reach the day when cryptographic security is so routine we don't even think about it, we have to start having it present _by default_. > > Kris S/MIME Cryptographic Signature
Re: SRA+IDEA Telnet
On Fri, 13 Aug 1999, Nick Sayer wrote: > I originally obtained SRA code from a University in Germany. I obtained > my implementation of IDEA from PGP. In fact, I used idea.[ch] and #if > 0'ed > out stuff that's not needed. Couldn't you work the code so it obtains all its' encryption functions from an external library, such as the system's libdes? That would let you export the code, since it doesn't provide any encryption functions itself, and international people could use the international DES library (for other encryption algorithms, pick a freely available implmenetation such as the one from openssl). I'm not sure what functionality this provides above something like SSLtelnet (in ports) or ssh, though. Probably much easier for folks to just use those. Kris To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Max simultaneous NFS mounts?
:On Thu, Aug 12, 1999 at 11:16:23PM -0700, Gregory Sutter wrote: :> What is the (default) maximum number of simultanous NFS mounts in :> FreeBSD 2.2.8 and 3.2? :> :> I was looking at 3.2 and it appears that 63 is the max, and this is :> tunable with kernel config option NFS_MUIDHASHSIZ. Is this correct? :> What is the maximum possible setting? : :Bleah. Strike that. NFS mounts don't seem to be any different from :normal mounts, so they just get inserted into mountlist, which is a :CIRCLEQ. This means that the only limitation is the amount of :available kernel memory, correct? : :Greg :-- :Gregory S. SutterCole's Law: Thinly sliced cabbage. NFS mounts allocate a dummy minor device number. I believe there is a limitation of 256 there. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Create a dump image of kernel
On Fri, 13 Aug 1999, Andrzej Bialecki wrote: > On Fri, 13 Aug 1999, Zhihui Zhang wrote: > > > > > Can anyone tell me how to modify the config file to build a kernel that > > creates dump image whenever it panics. Currently I have to use dumpon > > command after system bootup. But this command does not work when the > > panic happens during the bootup time, i.e., when you have no chance to > > issue the dumpon command. Thanks. > > This is a common problem recently, it seems.. See my recent postings to > this group (or was it -current?). > > Andrzej Bialecki It is in -current list. Subject is: is dumpon/savecore broken?. I read your postings there. It seems we can use remote GDB to debug a kernel that panics even before it probes the devices. I hope it is easy to learn how to use it from the handbook. Thanks. -Zhihui To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: SRA+IDEA Telnet
On Fri, 13 Aug 1999, Nick Sayer wrote: > I originally obtained SRA code from a University in Germany. I obtained > my implementation of IDEA from PGP. In fact, I used idea.[ch] and #if > 0'ed > out stuff that's not needed. Couldn't you work the code so it obtains all its' encryption functions from an external library, such as the system's libdes? That would let you export the code, since it doesn't provide any encryption functions itself, and international people could use the international DES library (for other encryption algorithms, pick a freely available implmenetation such as the one from openssl). I'm not sure what functionality this provides above something like SSLtelnet (in ports) or ssh, though. Probably much easier for folks to just use those. Kris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Max simultaneous NFS mounts?
On Thu, Aug 12, 1999 at 11:16:23PM -0700, Gregory Sutter wrote: > What is the (default) maximum number of simultanous NFS mounts in > FreeBSD 2.2.8 and 3.2? > > I was looking at 3.2 and it appears that 63 is the max, and this is > tunable with kernel config option NFS_MUIDHASHSIZ. Is this correct? > What is the maximum possible setting? Bleah. Strike that. NFS mounts don't seem to be any different from normal mounts, so they just get inserted into mountlist, which is a CIRCLEQ. This means that the only limitation is the amount of available kernel memory, correct? Greg -- Gregory S. SutterCole's Law: Thinly sliced cabbage. mailto:gsut...@pobox.com http://www.pobox.com/~gsutter/ PGP DSS public key 0x40AE3052 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: (2) hey
RFC 1035 isn't the only RFC under this aspect. While in RFC 1035 the host specification is a "should", in other RFC's it's a "must" They are: RFC 1123 Requirements for Internet Hosts -- Application and Support which has a pointer to RFC 952DOD INTERNET HOST TABLE SPECIFICATION So, underscores in Hostnames aren't allowed. They are not forbidden in the DNS specification (you can in fact use underscores in different context in DNS), but because of the RFC's above. You should also take a look at RFC 2181 Clarifications to the DNS Specification specifically Section 11 Daniel Evren Yurtesen schrieb: > > Well, I am the person who has this problem. > The RFCs does not explicitly say that we should not use underscore > character > as far as I understood. But it suggests which characters we should use. [...] To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Create a dump image of kernel
On Fri, 13 Aug 1999, Andrzej Bialecki wrote: > On Fri, 13 Aug 1999, Zhihui Zhang wrote: > > > > > Can anyone tell me how to modify the config file to build a kernel that > > creates dump image whenever it panics. Currently I have to use dumpon > > command after system bootup. But this command does not work when the > > panic happens during the bootup time, i.e., when you have no chance to > > issue the dumpon command. Thanks. > > This is a common problem recently, it seems.. See my recent postings to > this group (or was it -current?). > > Andrzej Bialecki It is in -current list. Subject is: is dumpon/savecore broken?. I read your postings there. It seems we can use remote GDB to debug a kernel that panics even before it probes the devices. I hope it is easy to learn how to use it from the handbook. Thanks. -Zhihui To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SRA+IDEA Telnet
Narvi wrote: > > How exactly do you plan to get this to the FreeBSD internationsl > server that has the crypto repository? The short answer is that I don't. Unfortunately the trick that PGP used of publishing it in a book and exporting that won't work anymore, because I believe the commerce department now says that source code printed in a book that can be scanned and OCRed is, in fact, "machine readable" and unexportable. I originally obtained SRA code from a University in Germany. I obtained my implementation of IDEA from PGP. In fact, I used idea.[ch] and #if 0'ed out stuff that's not needed. However, SRA is perfectly able to supply a compatable DES encryption key, so you can just add SRA to telnet and have SRA+DES. In fact, given that SRA isn't all that hard to break, one could argue that DES probably good enough (I hear it now -- if SRA isn't that hard to break, why bother? Answer: Because it's harder to break than plaintext. Factoring SRA would take a few days. Just watching for login: and password: takes nothing). I obtained the Makefiles for libtelnet, telnetd and telnet from the /usr/src/secure Attic and modified them so that they would enable encryption, authentication, SRA and DES (after adding SRA code, of course). I can discuss what I did with non-US citizens only in broad terms like the above. I can't assist and I can't provide source. The good news is that I believe the Bernstein case is headed finally for the Supreme Court and if all goes well source code may well be exempted from export regulations by deeming it protected speech. smime.p7s Description: S/MIME Cryptographic Signature
Re: Max simultaneous NFS mounts?
On Thu, Aug 12, 1999 at 11:16:23PM -0700, Gregory Sutter wrote: > What is the (default) maximum number of simultanous NFS mounts in > FreeBSD 2.2.8 and 3.2? > > I was looking at 3.2 and it appears that 63 is the max, and this is > tunable with kernel config option NFS_MUIDHASHSIZ. Is this correct? > What is the maximum possible setting? Bleah. Strike that. NFS mounts don't seem to be any different from normal mounts, so they just get inserted into mountlist, which is a CIRCLEQ. This means that the only limitation is the amount of available kernel memory, correct? Greg -- Gregory S. SutterCole's Law: Thinly sliced cabbage. mailto:[EMAIL PROTECTED] http://www.pobox.com/~gsutter/ PGP DSS public key 0x40AE3052 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: (2) hey
RFC 1035 isn't the only RFC under this aspect. While in RFC 1035 the host specification is a "should", in other RFC's it's a "must" They are: RFC 1123 Requirements for Internet Hosts -- Application and Support which has a pointer to RFC 952DOD INTERNET HOST TABLE SPECIFICATION So, underscores in Hostnames aren't allowed. They are not forbidden in the DNS specification (you can in fact use underscores in different context in DNS), but because of the RFC's above. You should also take a look at RFC 2181 Clarifications to the DNS Specification specifically Section 11 Daniel Evren Yurtesen schrieb: > > Well, I am the person who has this problem. > The RFCs does not explicitly say that we should not use underscore > character > as far as I understood. But it suggests which characters we should use. [...] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: (2) hey
Doug wrote: > >Nothing in either RFC that you quoted, or any of your examples >contradicted my actual point, which was that PTR records are not >valid outside of in-addr.arpa name space. AFAICT the second example I gave has a valid PTR record outside in-addr.arpa. To give you a more concrete example I've reconfigured the reverse DNS for dotat.at to change some time after midnight UTC to use the RR "rev.dotat.at. PTR dotat.at." >If you believe they are, give valid working examples and explain >their meaning, since there currently is not a definition for their >use outside of in-addr.arpa. It means that rev.dotat.at points to dotat.at. When the 134.240.212.in-addr.arpa zone updates itself rev.dotat.at will be the canonical name for 130.134.240.212.in-addr.arpa so reverse lookups will work as expected. You might also want to look at RFC 1886 which defines the ip6.int domain, which like in-addr.arpa is full of PTR RRs. Tony. -- f.a.n.finchd...@dotat.atf...@demon.nete pluribus unix To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: SRA+IDEA Telnet
Narvi wrote: > > How exactly do you plan to get this to the FreeBSD internationsl > server that has the crypto repository? The short answer is that I don't. Unfortunately the trick that PGP used of publishing it in a book and exporting that won't work anymore, because I believe the commerce department now says that source code printed in a book that can be scanned and OCRed is, in fact, "machine readable" and unexportable. I originally obtained SRA code from a University in Germany. I obtained my implementation of IDEA from PGP. In fact, I used idea.[ch] and #if 0'ed out stuff that's not needed. However, SRA is perfectly able to supply a compatable DES encryption key, so you can just add SRA to telnet and have SRA+DES. In fact, given that SRA isn't all that hard to break, one could argue that DES probably good enough (I hear it now -- if SRA isn't that hard to break, why bother? Answer: Because it's harder to break than plaintext. Factoring SRA would take a few days. Just watching for login: and password: takes nothing). I obtained the Makefiles for libtelnet, telnetd and telnet from the /usr/src/secure Attic and modified them so that they would enable encryption, authentication, SRA and DES (after adding SRA code, of course). I can discuss what I did with non-US citizens only in broad terms like the above. I can't assist and I can't provide source. The good news is that I believe the Bernstein case is headed finally for the Supreme Court and if all goes well source code may well be exempted from export regulations by deeming it protected speech. S/MIME Cryptographic Signature
Re: SRA+IDEA Telnet
How exactly do you plan to get this to the FreeBSD internationsl server that has the crypto repository? Sander There is no love, no good, no happiness and no future - all these are just illusions. On Thu, 12 Aug 1999, Nick Sayer wrote: > Ok. I have put up a rough cut of my proposed src/crypto/telnet stuff > with SRA > authentication and IDEA encryption. It requires the libutil from 3.2 (or > better), > but it appears to work pretty well. > > Please don't download it if you're outside the US. > > But if you are in the US, you can grab it from > ftp://ftp.kfu.com/pub/sra-idea.FreeBSD-32.tgz > > Move your existing /usr/src/crypto/telnet out of the way and unpack the > tgz into /usr/src/crypto. > > Then cd into telnet and make. > > In particular, anyone who sees any stupid stuff in the Makefiles (I had > to guess a lot) or > anything that would break existing (kerberos) functionality, please let > me know. > It seems to me, though, that since there were no Makefiles in there > before the kerberos stuff > must be using its own Makefiles with these source files or some such > magic. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Create a dump image of kernel
On Fri, 13 Aug 1999, Zhihui Zhang wrote: > > Can anyone tell me how to modify the config file to build a kernel that > creates dump image whenever it panics. Currently I have to use dumpon > command after system bootup. But this command does not work when the > panic happens during the bootup time, i.e., when you have no chance to > issue the dumpon command. Thanks. This is a common problem recently, it seems.. See my recent postings to this group (or was it -current?). Andrzej Bialecki // 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: New tests for test(1)
On Fri, 13 Aug 1999, Sheldon Hearn wrote: > > > On Fri, 13 Aug 1999 12:50:54 -0400, "Brian F. Feldman" wrote: > > > I fully agree with this. If it can be cleanly added to the current test(1) > > (which it can), we should have it, even if it were JUST for the sake of > > portability. > > Ah, but I'm not proposing that we add new functionality to the existing > test(1). The code gave me a head-ache. I'm proposing that we replace our > test(1) entirely. > > Ciao, > Sheldon. > I don't see how our test is that bad. It's doing something right if the functionality is so easy to add... Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: New tests for test(1)
On Fri, 13 Aug 1999 12:50:54 -0400, "Brian F. Feldman" wrote: > I fully agree with this. If it can be cleanly added to the current test(1) > (which it can), we should have it, even if it were JUST for the sake of > portability. Ah, but I'm not proposing that we add new functionality to the existing test(1). The code gave me a head-ache. I'm proposing that we replace our test(1) entirely. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: libcompat proposition
On Fri, 13 Aug 1999 12:52:05 -0400, "Brian F. Feldman" wrote: > Direct veto by core member (Jordan) prevents this. I really think it > should be in libcompat, the more I consider every option. Regardless of what Jordan says, you should do your best to put it where most other folks put it. Otherwise, you'll end up with source that expects it in one library while FreeBSD is a special case for which you need to link against another. Just look at Linux with their libnet. :-) Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: libcompat proposition
On Fri, 13 Aug 1999, Jamie Howard wrote: > On Fri, 13 Aug 1999, Sheldon Hearn wrote: > > > Close, but what I said was more along the lines that following NetBSD's > > footsteps on issues relating to portability is _seldom_ a bad idea. > > I was close enough that you know the exact quote so I think I did alright. > > Back to the point, just stick it in libc :) Direct veto by core member (Jordan) prevents this. I really think it should be in libcompat, the more I consider every option. > > Jamie > Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: New tests for test(1)
On Fri, 13 Aug 1999, Sheldon Hearn wrote: > > > On Fri, 13 Aug 1999 15:36:24 +1000, Peter Jeremy wrote: > > > It would be nice, but there are portability issues. > > Hi Peter, > > I'm only replying to your mail because you're the last person to mention > portability as a case againsdt NetBSD's test(1). > > Just how many other platforms need to support an _extension_ that is > _fully_ backward compatible before we'll consider implementing it? > > With this attitude driving us, we'll end up being the only OS that > doesn't support a number of fetures, all in the name of portability. :-) I fully agree with this. If it can be cleanly added to the current test(1) (which it can), we should have it, even if it were JUST for the sake of portability. I don't see why we shouldn't add it. I mean, /bin/sh is already a bastardized shell that's partway to ksh, so we could at least support more features than we do now :) > > Ciao, > Sheldon. > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message > Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: (2) hey
Doug <[EMAIL PROTECTED]> wrote: > >Nothing in either RFC that you quoted, or any of your examples >contradicted my actual point, which was that PTR records are not >valid outside of in-addr.arpa name space. AFAICT the second example I gave has a valid PTR record outside in-addr.arpa. To give you a more concrete example I've reconfigured the reverse DNS for dotat.at to change some time after midnight UTC to use the RR "rev.dotat.at. PTR dotat.at." >If you believe they are, give valid working examples and explain >their meaning, since there currently is not a definition for their >use outside of in-addr.arpa. It means that rev.dotat.at points to dotat.at. When the 134.240.212.in-addr.arpa zone updates itself rev.dotat.at will be the canonical name for 130.134.240.212.in-addr.arpa so reverse lookups will work as expected. You might also want to look at RFC 1886 which defines the ip6.int domain, which like in-addr.arpa is full of PTR RRs. Tony. -- f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]e pluribus unix To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: libcompat proposition
On Fri, 13 Aug 1999, Sheldon Hearn wrote: > Close, but what I said was more along the lines that following NetBSD's > footsteps on issues relating to portability is _seldom_ a bad idea. I was close enough that you know the exact quote so I think I did alright. Back to the point, just stick it in libc :) Jamie To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: SRA+IDEA Telnet
How exactly do you plan to get this to the FreeBSD internationsl server that has the crypto repository? Sander There is no love, no good, no happiness and no future - all these are just illusions. On Thu, 12 Aug 1999, Nick Sayer wrote: > Ok. I have put up a rough cut of my proposed src/crypto/telnet stuff > with SRA > authentication and IDEA encryption. It requires the libutil from 3.2 (or > better), > but it appears to work pretty well. > > Please don't download it if you're outside the US. > > But if you are in the US, you can grab it from > ftp://ftp.kfu.com/pub/sra-idea.FreeBSD-32.tgz > > Move your existing /usr/src/crypto/telnet out of the way and unpack the > tgz into /usr/src/crypto. > > Then cd into telnet and make. > > In particular, anyone who sees any stupid stuff in the Makefiles (I had > to guess a lot) or > anything that would break existing (kerberos) functionality, please let > me know. > It seems to me, though, that since there were no Makefiles in there > before the kerberos stuff > must be using its own Makefiles with these source files or some such > magic. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Create a dump image of kernel
On Fri, 13 Aug 1999, Zhihui Zhang wrote: > > Can anyone tell me how to modify the config file to build a kernel that > creates dump image whenever it panics. Currently I have to use dumpon > command after system bootup. But this command does not work when the > panic happens during the bootup time, i.e., when you have no chance to > issue the dumpon command. Thanks. This is a common problem recently, it seems.. See my recent postings to this group (or was it -current?). 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: New tests for test(1)
On Fri, 13 Aug 1999, Sheldon Hearn wrote: > > > On Fri, 13 Aug 1999 12:50:54 -0400, "Brian F. Feldman" wrote: > > > I fully agree with this. If it can be cleanly added to the current test(1) > > (which it can), we should have it, even if it were JUST for the sake of > > portability. > > Ah, but I'm not proposing that we add new functionality to the existing > test(1). The code gave me a head-ache. I'm proposing that we replace our > test(1) entirely. > > Ciao, > Sheldon. > I don't see how our test is that bad. It's doing something right if the functionality is so easy to add... Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: New tests for test(1)
On Fri, 13 Aug 1999 12:50:54 -0400, "Brian F. Feldman" wrote: > I fully agree with this. If it can be cleanly added to the current test(1) > (which it can), we should have it, even if it were JUST for the sake of > portability. Ah, but I'm not proposing that we add new functionality to the existing test(1). The code gave me a head-ache. I'm proposing that we replace our test(1) entirely. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: libcompat proposition
On Fri, 13 Aug 1999 12:52:05 -0400, "Brian F. Feldman" wrote: > Direct veto by core member (Jordan) prevents this. I really think it > should be in libcompat, the more I consider every option. Regardless of what Jordan says, you should do your best to put it where most other folks put it. Otherwise, you'll end up with source that expects it in one library while FreeBSD is a special case for which you need to link against another. Just look at Linux with their libnet. :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: libcompat proposition
On Fri, 13 Aug 1999, Jamie Howard wrote: > On Fri, 13 Aug 1999, Sheldon Hearn wrote: > > > Close, but what I said was more along the lines that following NetBSD's > > footsteps on issues relating to portability is _seldom_ a bad idea. > > I was close enough that you know the exact quote so I think I did alright. > > Back to the point, just stick it in libc :) Direct veto by core member (Jordan) prevents this. I really think it should be in libcompat, the more I consider every option. > > Jamie > Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: New tests for test(1)
On Fri, 13 Aug 1999, Sheldon Hearn wrote: > > > On Fri, 13 Aug 1999 15:36:24 +1000, Peter Jeremy wrote: > > > It would be nice, but there are portability issues. > > Hi Peter, > > I'm only replying to your mail because you're the last person to mention > portability as a case againsdt NetBSD's test(1). > > Just how many other platforms need to support an _extension_ that is > _fully_ backward compatible before we'll consider implementing it? > > With this attitude driving us, we'll end up being the only OS that > doesn't support a number of fetures, all in the name of portability. :-) I fully agree with this. If it can be cleanly added to the current test(1) (which it can), we should have it, even if it were JUST for the sake of portability. I don't see why we shouldn't add it. I mean, /bin/sh is already a bastardized shell that's partway to ksh, so we could at least support more features than we do now :) > > Ciao, > Sheldon. > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: libcompat proposition
On Fri, 13 Aug 1999 09:16:09 -0400, Jamie Howard wrote: > I saw someone say that anything NetBSD did in the name of portability must > be right (in the test thread). :) Close, but what I said was more along the lines that following NetBSD's footsteps on issues relating to portability is _seldom_ a bad idea. :-) Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: (2) hey
Tony Finch wrote: > > Doug wrote: > >Louis A. Mamakos wrote: > >>[lost attribution] > >>> > >>> That IS a violation of the standard, since A records are not valid > >>> for hosts in in-addr.arpa. > >> > >> And next I suppose you'll tell me that PTR records are not valid > >> outsize of the IN-ADDR.ARPA portion of the DNS namespace? > > > > Given how PTR RR's are defined, I'd have to say, ayyup. > > I suggest you read RFC 2317 I'd suggest you read what I actually wrote. :) Nothing in either RFC that you quoted, or any of your examples contradicted my actual point, which was that PTR records are not valid outside of in-addr.arpa name space. If you believe they are, give valid working examples and explain their meaning, since there currently is not a definition for their use outside of in-addr.arpa. Doug To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: libcompat proposition
On Fri, 13 Aug 1999, Sheldon Hearn wrote: > Close, but what I said was more along the lines that following NetBSD's > footsteps on issues relating to portability is _seldom_ a bad idea. I was close enough that you know the exact quote so I think I did alright. Back to the point, just stick it in libc :) Jamie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Create a dump image of kernel
Can anyone tell me how to modify the config file to build a kernel that creates dump image whenever it panics. Currently I have to use dumpon command after system bootup. But this command does not work when the panic happens during the bootup time, i.e., when you have no chance to issue the dumpon command. Thanks. -- 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
[Review please] (was: Re: cvs commit: src/gnu/usr.bin/man/manpath manpath.config)
On Thu, Aug 12, 1999 at 04:19:59PM +0200, Dag-Erling Smorgrav wrote:
> Ruslan Ermilov writes:
> > Hmm, looking to the p5-* ports, I can't figure out what would be the
> > appropriate PATH component for /usr/local/lib/perl/*/man manpath.
> > Do you have an idea?
>
> You can't use MANPATH_MAP for /usr/local/lib/perl/*/man, because these
> man pages correpsond to Perl modules, not to binaries. You have to use
> MANDATORY_MANPATH, or some variation thereof.
>
DES, Mark, -hackers!
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.
Additionally, this patch fixes two other bugs:
1) The order of directives in manpath.config is honored, which is bogus.
Run manpath (with and without -d flag) against the following config
and see what happens:
MANPATH_MAP /usr/local/bin /usr/local/man
MANDATORY_MANPATH /usr/share/man
MANDATORY_MANPATH /usr/share/perl/man
2) Infinite loop when the PATH isn't set or NULL, and MANDATORY_MANPATH
directory doesn't exist. Run `/usr/bin/env PATH= /usr/bin/manpath'
or, better yet, `/usr/bin/env PATH= /usr/bin/man man' against the
following manpath.config:
MANDATORY_MANPATH /usr/share/man
MANDATORY_MANPATH /nonexistent
Cheers,
--
Ruslan Ermilov Sysadmin and DBA of the
r...@ucb.crimea.ua United Commercial Bank,
r...@freebsd.orgFreeBSD committer,
+380.652.247.647Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
Index: manpath.config
===
RCS file: /usr/FreeBSD-CVS/src/gnu/usr.bin/man/manpath/manpath.config,v
retrieving revision 1.11
diff -u -c -r1.11 manpath.config
*** manpath.config 1999/07/25 19:33:06 1.11
--- manpath.config 1999/08/13 14:17:38
***
*** 6,11
--- 6,12
#
# MANBIN pathname
# MANDATORY_MANPATH manpath_element
+ # OPTIONAL_MANPATHmanpath_element
# MANPATH_MAP path_elementmanpath_element
#
# MANBIN is optional
***
*** 16,24
#
MANDATORY_MANPATH /usr/share/man
MANDATORY_MANPATH /usr/share/perl/man
! #MANDATORY_MANPATH/usr/local/man
! #MANDATORY_MANPATH/usr/local/lib/perl5/5.00503/man
! MANDATORY_MANPATH /usr/X11R6/man
#
# set up PATH to MANPATH mapping
#
--- 17,23
#
MANDATORY_MANPATH /usr/share/man
MANDATORY_MANPATH /usr/share/perl/man
! OPTIONAL_MANPATH /usr/local/lib/perl5/5.00503/man
#
# set up PATH to MANPATH mapping
#
Index: manpath.h
===
RCS file: /usr/FreeBSD-CVS/src/gnu/usr.bin/man/manpath/manpath.h,v
retrieving revision 1.2
diff -u -c -r1.2 manpath.h
*** manpath.h 1995/05/30 05:02:06 1.2
--- manpath.h 1999/08/13 14:17:38
***
*** 18,25
{
char mandir[MAXPATHLEN];
char bin[MAXPATHLEN];
! int mandatory;
} DIRLIST;
DIRLIST list[MAXDIRS];
--- 18,31
{
char mandir[MAXPATHLEN];
char bin[MAXPATHLEN];
! int type;
} DIRLIST;
+
+ /* manpath types */
+ #define MANPATH_NONE 0
+ #define MANPATH_MANDATORY 1 /* manpath is mandatory */
+ #define MANPATH_OPTIONAL 2 /* manpath is optional */
+ #define MANPATH_MAP 3 /* maps path to manpath */
DIRLIST list[MAXDIRS];
Index: manpath.c
===
RCS file: /usr/FreeBSD-CVS/src/gnu/usr.bin/man/manpath/manpath.c,v
retrieving revision 1.6
diff -u -c -r1.6 manpath.c
*** manpath.c 1998/07/09 12:39:08 1.6
--- manpath.c 1999/08/13 14:17:38
***
*** 203,209
if (!strncmp ("MANBIN", bp, 6))
continue;
! if (!strncmp ("MANDATORY_MANPATH", bp, 17))
{
if ((p = strchr (bp, ' ')) == NULL &&
(p = strchr (bp, '\t')) == NULL) {
--- 203,210
if (!strncmp ("MANBIN", bp, 6))
continue;
! if (!strncmp ("MANDATORY_MANPATH", bp, 17) ||
! !strncmp ("OPTIONAL_MANPATH", bp, 16))
{
if ((p = strchr (bp, ' ')) == NULL &&
(p = strchr (bp, '\t')) == NULL) {
***
*** 211,219
return -1;
}
! bp = p;
! dlp->mandatory = 1;
while (*bp && *bp != '\n' && (*bp == ' ' || *bp == '\t'))
bp++;
--- 212,220
return -1;
}
! dlp->type = *bp == 'M'? MANPATH_MANDATORY: MANPATH_OPTIONAL;
! bp = p;
while (*bp && *bp != '\n' && (*bp == ' ' || *bp == '\t'))
bp++;
***
*** 224,230
dlp->mandir[i] = '\0';
if (debug)
! fprintf (stderr, "fou
Re: libcompat proposition
On Fri, 13 Aug 1999 09:16:09 -0400, Jamie Howard wrote: > I saw someone say that anything NetBSD did in the name of portability must > be right (in the test thread). :) Close, but what I said was more along the lines that following NetBSD's footsteps on issues relating to portability is _seldom_ a bad idea. :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: (2) hey
Tony Finch wrote: > > Doug <[EMAIL PROTECTED]> wrote: > >Louis A. Mamakos wrote: > >>[lost attribution] > >>> > >>> That IS a violation of the standard, since A records are not valid > >>> for hosts in in-addr.arpa. > >> > >> And next I suppose you'll tell me that PTR records are not valid > >> outsize of the IN-ADDR.ARPA portion of the DNS namespace? > > > > Given how PTR RR's are defined, I'd have to say, ayyup. > > I suggest you read RFC 2317 I'd suggest you read what I actually wrote. :) Nothing in either RFC that you quoted, or any of your examples contradicted my actual point, which was that PTR records are not valid outside of in-addr.arpa name space. If you believe they are, give valid working examples and explain their meaning, since there currently is not a definition for their use outside of in-addr.arpa. Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
SRA+IDEA Telnet
Ok. I have put up a rough cut of my proposed src/crypto/telnet stuff with SRA authentication and IDEA encryption. It requires the libutil from 3.2 (or better), but it appears to work pretty well. Please don't download it if you're outside the US. But if you are in the US, you can grab it from ftp://ftp.kfu.com/pub/sra-idea.FreeBSD-32.tgz Move your existing /usr/src/crypto/telnet out of the way and unpack the tgz into /usr/src/crypto. Then cd into telnet and make. In particular, anyone who sees any stupid stuff in the Makefiles (I had to guess a lot) or anything that would break existing (kerberos) functionality, please let me know. It seems to me, though, that since there were no Makefiles in there before the kerberos stuff must be using its own Makefiles with these source files or some such magic. smime.p7s Description: S/MIME Cryptographic Signature
Re: New tests for test(1)
Hi folks,
The pdksh-derived test(1) used by NetBSD and OpenBSD has made it through
a ``make world'' and package run on my box. It passes the regression
tests supplied with our own test(1) in exactly the same way as our own
test(1) does, and shows no noticeable performance difference.
I've mentioned several times that portability is a non-issue here
and haven't heard any rebuttals. I have a PR open (PR 13091) for
replacing our test(1) with the one used by {Net,Open}BSD. The
PR contains a diff which you should ignore. Rather look at
http://www.freebsd.org/~sheldonh/test/ :-)
So are there any reasonable ojections to our following the lead of our
sister free-BSD's?
Ciao,
Sheldon.
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Create a dump image of kernel
Can anyone tell me how to modify the config file to build a kernel that creates dump image whenever it panics. Currently I have to use dumpon command after system bootup. But this command does not work when the panic happens during the bootup time, i.e., when you have no chance to issue the dumpon command. Thanks. -- 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
[Review please] (was: Re: cvs commit: src/gnu/usr.bin/man/manpath manpath.config)
On Thu, Aug 12, 1999 at 04:19:59PM +0200, Dag-Erling Smorgrav wrote:
> Ruslan Ermilov <[EMAIL PROTECTED]> writes:
> > Hmm, looking to the p5-* ports, I can't figure out what would be the
> > appropriate PATH component for /usr/local/lib/perl/*/man manpath.
> > Do you have an idea?
>
> You can't use MANPATH_MAP for /usr/local/lib/perl/*/man, because these
> man pages correpsond to Perl modules, not to binaries. You have to use
> MANDATORY_MANPATH, or some variation thereof.
>
DES, Mark, -hackers!
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.
Additionally, this patch fixes two other bugs:
1) The order of directives in manpath.config is honored, which is bogus.
Run manpath (with and without -d flag) against the following config
and see what happens:
MANPATH_MAP /usr/local/bin /usr/local/man
MANDATORY_MANPATH /usr/share/man
MANDATORY_MANPATH /usr/share/perl/man
2) Infinite loop when the PATH isn't set or NULL, and MANDATORY_MANPATH
directory doesn't exist. Run `/usr/bin/env PATH= /usr/bin/manpath'
or, better yet, `/usr/bin/env PATH= /usr/bin/man man' against the
following manpath.config:
MANDATORY_MANPATH /usr/share/man
MANDATORY_MANPATH /nonexistent
Cheers,
--
Ruslan Ermilov Sysadmin and DBA of the
[EMAIL PROTECTED]United Commercial Bank,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.247.647Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
Index: manpath.config
===
RCS file: /usr/FreeBSD-CVS/src/gnu/usr.bin/man/manpath/manpath.config,v
retrieving revision 1.11
diff -u -c -r1.11 manpath.config
*** manpath.config 1999/07/25 19:33:06 1.11
--- manpath.config 1999/08/13 14:17:38
***
*** 6,11
--- 6,12
#
# MANBIN pathname
# MANDATORY_MANPATH manpath_element
+ # OPTIONAL_MANPATHmanpath_element
# MANPATH_MAP path_elementmanpath_element
#
# MANBIN is optional
***
*** 16,24
#
MANDATORY_MANPATH /usr/share/man
MANDATORY_MANPATH /usr/share/perl/man
! #MANDATORY_MANPATH/usr/local/man
! #MANDATORY_MANPATH/usr/local/lib/perl5/5.00503/man
! MANDATORY_MANPATH /usr/X11R6/man
#
# set up PATH to MANPATH mapping
#
--- 17,23
#
MANDATORY_MANPATH /usr/share/man
MANDATORY_MANPATH /usr/share/perl/man
! OPTIONAL_MANPATH /usr/local/lib/perl5/5.00503/man
#
# set up PATH to MANPATH mapping
#
Index: manpath.h
===
RCS file: /usr/FreeBSD-CVS/src/gnu/usr.bin/man/manpath/manpath.h,v
retrieving revision 1.2
diff -u -c -r1.2 manpath.h
*** manpath.h 1995/05/30 05:02:06 1.2
--- manpath.h 1999/08/13 14:17:38
***
*** 18,25
{
char mandir[MAXPATHLEN];
char bin[MAXPATHLEN];
! int mandatory;
} DIRLIST;
DIRLIST list[MAXDIRS];
--- 18,31
{
char mandir[MAXPATHLEN];
char bin[MAXPATHLEN];
! int type;
} DIRLIST;
+
+ /* manpath types */
+ #define MANPATH_NONE 0
+ #define MANPATH_MANDATORY 1 /* manpath is mandatory */
+ #define MANPATH_OPTIONAL 2 /* manpath is optional */
+ #define MANPATH_MAP 3 /* maps path to manpath */
DIRLIST list[MAXDIRS];
Index: manpath.c
===
RCS file: /usr/FreeBSD-CVS/src/gnu/usr.bin/man/manpath/manpath.c,v
retrieving revision 1.6
diff -u -c -r1.6 manpath.c
*** manpath.c 1998/07/09 12:39:08 1.6
--- manpath.c 1999/08/13 14:17:38
***
*** 203,209
if (!strncmp ("MANBIN", bp, 6))
continue;
! if (!strncmp ("MANDATORY_MANPATH", bp, 17))
{
if ((p = strchr (bp, ' ')) == NULL &&
(p = strchr (bp, '\t')) == NULL) {
--- 203,210
if (!strncmp ("MANBIN", bp, 6))
continue;
! if (!strncmp ("MANDATORY_MANPATH", bp, 17) ||
! !strncmp ("OPTIONAL_MANPATH", bp, 16))
{
if ((p = strchr (bp, ' ')) == NULL &&
(p = strchr (bp, '\t')) == NULL) {
***
*** 211,219
return -1;
}
! bp = p;
! dlp->mandatory = 1;
while (*bp && *bp != '\n' && (*bp == ' ' || *bp == '\t'))
bp++;
--- 212,220
return -1;
}
! dlp->type = *bp == 'M'? MANPATH_MANDATORY: MANPATH_OPTIONAL;
! bp = p;
while (*bp && *bp != '\n' && (*bp == ' ' || *bp == '\t'))
bp++;
***
*** 224,230
dlp->mandir[i] = '\0';
if (debug)
! fpr
Re: mmap bug
Arun Sharma writes: > The daemons which are involved in freeing up pages during low memory > conditions qualify as system daemons. Making sure that these daemons > don't block avoids the deadlock. > > -Arun The second solution involves a little more than that. Such as blessing "normal" jobs just enough to allow them to get sufficent resources to avoid a deadlock. One instance of the mmap lockup involves a case where you've got a single process dirtying a memory mapped file which is larger than physical memory. Assuming an otherwise idle system, nearly all available memory in the system will belong to the file's object & it will all be dirty. At some point, the process will trigger a fault on a non-resident page. vm_fault will call the vnode_pager_getpages to read in the faulting page. ffs_getpages (let's assume we're using ffs) will then call ffs_read to read in the pages. ffs_read will try to build a cluster. The deadlock occurs when allocbuf cannot allocate a page for one of the pages in the cluster. Here's a stack trace (from a long, long time ago, May 12th): db> tr vm_page_alloc(caa0a074,d1d,0,c58f7ba0,1fc) at vm_page_alloc allocbuf(c58f7ba0,2000,0,c58c4588,5) at allocbuf+0x3ae getblk(caa0f8c0,68e,2000,0,0) at getblk+0x32e cluster_rbuild(caa0f8c0,801,0,689,370b0) at cluster_rbuild+0x1df cluster_read(caa0f8c0,801,0,689,2000) at cluster_read+0x2cc ffs_read(caa12e28) at ffs_read+0x3ea ffs_getpages(caa12e80) at ffs_getpages+0x22c vnode_pager_getpages(caa0a074,caa12f14,1,0,c9fcdce0) at vnode_pager_getpages+0x4e vm_fault(c9fd28c0,48df9000,3,8,c9fcdce0) at vm_fault+0x484 trap_pfault(caa12fb8,1,48df9000) at trap_pfault+0xaa trap(2f,2f,2f,48df9000,48df9000) at trap+0x1aa calltrap() at calltrap+0x1c The real problem is that the pageout daemon cannot push any pages because (nearly) all the pages available to user-processes are held by the mmap'ed object. The killer is that they are all dirty & that because we're in the middle of doing a cluster read, the vnode is locked so the pageout daemon cannot touch them. A solution would be allowing the faulting process to dip into the system reserves enough so that the vm_page_alloc will succeed, which will allow the cluster read to complete. This will avoid deadlock. I personally think the first solution (always taking write faults) would be far, far better. This would allow the system to avoid getting anywhere near a deadlock situation & to remain responsive. I'm afraid that if we go with the second solution, the system would be unresponsive until the cluster read completed & the pageout daemon was able begin to flush the dirty pages in the offending object. -- Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: galla...@cs.duke.edu Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: libcompat proposition
On Thu, 12 Aug 1999, Jamie Howard wrote: > How would those functions which also exist in libc (or possibly other > libraries, I don't know) be handled? Just following up to myself here, NetBSD has a getopt_long() in libc ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/lib/libc/stdlib/ I saw someone say that anything NetBSD did in the name of portability must be right (in the test thread). :) Jamie To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
SRA+IDEA Telnet
Ok. I have put up a rough cut of my proposed src/crypto/telnet stuff with SRA authentication and IDEA encryption. It requires the libutil from 3.2 (or better), but it appears to work pretty well. Please don't download it if you're outside the US. But if you are in the US, you can grab it from ftp://ftp.kfu.com/pub/sra-idea.FreeBSD-32.tgz Move your existing /usr/src/crypto/telnet out of the way and unpack the tgz into /usr/src/crypto. Then cd into telnet and make. In particular, anyone who sees any stupid stuff in the Makefiles (I had to guess a lot) or anything that would break existing (kerberos) functionality, please let me know. It seems to me, though, that since there were no Makefiles in there before the kerberos stuff must be using its own Makefiles with these source files or some such magic. S/MIME Cryptographic Signature
Re: New tests for test(1)
Hi folks,
The pdksh-derived test(1) used by NetBSD and OpenBSD has made it through
a ``make world'' and package run on my box. It passes the regression
tests supplied with our own test(1) in exactly the same way as our own
test(1) does, and shows no noticeable performance difference.
I've mentioned several times that portability is a non-issue here
and haven't heard any rebuttals. I have a PR open (PR 13091) for
replacing our test(1) with the one used by {Net,Open}BSD. The
PR contains a diff which you should ignore. Rather look at
http://www.freebsd.org/~sheldonh/test/ :-)
So are there any reasonable ojections to our following the lead of our
sister free-BSD's?
Ciao,
Sheldon.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: (2) hey
Doug wrote: >Louis A. Mamakos wrote: >>[lost attribution] >>> >>> That IS a violation of the standard, since A records are not valid >>> for hosts in in-addr.arpa. >> >> And next I suppose you'll tell me that PTR records are not valid >> outsize of the IN-ADDR.ARPA portion of the DNS namespace? > > Given how PTR RR's are defined, I'd have to say, ayyup. I suggest you read RFC 2317 (classless reverse DNS). Among its recommendations are setups like: 130.134.240.212.in-addr.arpa.CNAME 130.128/28.134.240.212.in-addr.arpa. 130.128/28.134.240.212.in-addr.arpa. PTR dotat.at. and: 130.134.240.212.in-addr.arpa. CNAME 130.rev.dotat.at. 130.rev.dotat.at PTR dotat.at. RFC 2181 allows the / in the CNAME RRs. There's no reason for restricting PTR RRs to a particular part of the name space, and indeed this example shows that doing so can make administration unnecessarily harder. The real reverse DNS for dotat.at uses this more conservative setup: 130.134.240.212.in-addr.arpa.CNAME 130.128-28.134.240.212.in-addr.arpa. 130.128-28.134.240.212.in-addr.arpa. PTR dotat.at. Tony. -- f.a.n.finchd...@dotat.atf...@demon.nete pluribus unix To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: mmap bug
Arun Sharma writes: > The daemons which are involved in freeing up pages during low memory > conditions qualify as system daemons. Making sure that these daemons > don't block avoids the deadlock. > > -Arun The second solution involves a little more than that. Such as blessing "normal" jobs just enough to allow them to get sufficent resources to avoid a deadlock. One instance of the mmap lockup involves a case where you've got a single process dirtying a memory mapped file which is larger than physical memory. Assuming an otherwise idle system, nearly all available memory in the system will belong to the file's object & it will all be dirty. At some point, the process will trigger a fault on a non-resident page. vm_fault will call the vnode_pager_getpages to read in the faulting page. ffs_getpages (let's assume we're using ffs) will then call ffs_read to read in the pages. ffs_read will try to build a cluster. The deadlock occurs when allocbuf cannot allocate a page for one of the pages in the cluster. Here's a stack trace (from a long, long time ago, May 12th): db> tr vm_page_alloc(caa0a074,d1d,0,c58f7ba0,1fc) at vm_page_alloc allocbuf(c58f7ba0,2000,0,c58c4588,5) at allocbuf+0x3ae getblk(caa0f8c0,68e,2000,0,0) at getblk+0x32e cluster_rbuild(caa0f8c0,801,0,689,370b0) at cluster_rbuild+0x1df cluster_read(caa0f8c0,801,0,689,2000) at cluster_read+0x2cc ffs_read(caa12e28) at ffs_read+0x3ea ffs_getpages(caa12e80) at ffs_getpages+0x22c vnode_pager_getpages(caa0a074,caa12f14,1,0,c9fcdce0) at vnode_pager_getpages+0x4e vm_fault(c9fd28c0,48df9000,3,8,c9fcdce0) at vm_fault+0x484 trap_pfault(caa12fb8,1,48df9000) at trap_pfault+0xaa trap(2f,2f,2f,48df9000,48df9000) at trap+0x1aa calltrap() at calltrap+0x1c The real problem is that the pageout daemon cannot push any pages because (nearly) all the pages available to user-processes are held by the mmap'ed object. The killer is that they are all dirty & that because we're in the middle of doing a cluster read, the vnode is locked so the pageout daemon cannot touch them. A solution would be allowing the faulting process to dip into the system reserves enough so that the vm_page_alloc will succeed, which will allow the cluster read to complete. This will avoid deadlock. I personally think the first solution (always taking write faults) would be far, far better. This would allow the system to avoid getting anywhere near a deadlock situation & to remain responsive. I'm afraid that if we go with the second solution, the system would be unresponsive until the cluster read completed & the pageout daemon was able begin to flush the dirty pages in the offending object. -- Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: [EMAIL PROTECTED] Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: libcompat proposition
On Thu, 12 Aug 1999, Jamie Howard wrote: > How would those functions which also exist in libc (or possibly other > libraries, I don't know) be handled? Just following up to myself here, NetBSD has a getopt_long() in libc ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/lib/libc/stdlib/ I saw someone say that anything NetBSD did in the name of portability must be right (in the test thread). :) Jamie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: (2) hey
Doug <[EMAIL PROTECTED]> wrote: >Louis A. Mamakos wrote: >>[lost attribution] >>> >>> That IS a violation of the standard, since A records are not valid >>> for hosts in in-addr.arpa. >> >> And next I suppose you'll tell me that PTR records are not valid >> outsize of the IN-ADDR.ARPA portion of the DNS namespace? > > Given how PTR RR's are defined, I'd have to say, ayyup. I suggest you read RFC 2317 (classless reverse DNS). Among its recommendations are setups like: 130.134.240.212.in-addr.arpa.CNAME 130.128/28.134.240.212.in-addr.arpa. 130.128/28.134.240.212.in-addr.arpa. PTR dotat.at. and: 130.134.240.212.in-addr.arpa. CNAME 130.rev.dotat.at. 130.rev.dotat.at PTR dotat.at. RFC 2181 allows the / in the CNAME RRs. There's no reason for restricting PTR RRs to a particular part of the name space, and indeed this example shows that doing so can make administration unnecessarily harder. The real reverse DNS for dotat.at uses this more conservative setup: 130.134.240.212.in-addr.arpa.CNAME 130.128-28.134.240.212.in-addr.arpa. 130.128-28.134.240.212.in-addr.arpa. PTR dotat.at. Tony. -- f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]e pluribus unix To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: New tests for test(1)
On Fri, 13 Aug 1999 15:36:24 +1000, Peter Jeremy wrote: > It would be nice, but there are portability issues. Hi Peter, I'm only replying to your mail because you're the last person to mention portability as a case againsdt NetBSD's test(1). Just how many other platforms need to support an _extension_ that is _fully_ backward compatible before we'll consider implementing it? With this attitude driving us, we'll end up being the only OS that doesn't support a number of fetures, all in the name of portability. :-) Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: New tests for test(1)
On Thu, 12 Aug 1999 11:41:31 -0400, "Brian F. Feldman" wrote: > > NetBSD's test(1) utility has this (-nt and -ot). We should probably > > merge in their changes. > > Hmm... this is in pdksh too... Don't go there. :-) Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: New tests for test(1)
On Fri, 13 Aug 1999 15:36:24 +1000, Peter Jeremy wrote: > It would be nice, but there are portability issues. Hi Peter, I'm only replying to your mail because you're the last person to mention portability as a case againsdt NetBSD's test(1). Just how many other platforms need to support an _extension_ that is _fully_ backward compatible before we'll consider implementing it? With this attitude driving us, we'll end up being the only OS that doesn't support a number of fetures, all in the name of portability. :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: New tests for test(1)
On Thu, 12 Aug 1999 11:41:31 -0400, "Brian F. Feldman" wrote: > > NetBSD's test(1) utility has this (-nt and -ot). We should probably > > merge in their changes. > > Hmm... this is in pdksh too... Don't go there. :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Threaded X libraries
On Fri, 13 Aug 1999, Stephen Hocking-Senior Programmer PGS Tensor Perth wrote: > I'm attempting to build the X11 libs with the thread safety stuff (I beleive > Linux can already be built like this) and have discovered when linking that > we > don't have the getpwnam_r & getpwuid_r functions in out libc_r. Is anyone > planning on adding these? > > > Stephen > See the archives - I think it has already come up at least once. Sander There is no love, no good, no happiness and no future - all these are just illusions. > It's all part of my plan to make SDL (Sam Lantinga's Simple Direct Media > Layer) work. It dies quite frequently when starting sound & graphics in some > of the test apps. I am suspicious that it requires a threadsafe libX11. > -- > The views expressed above are not those of PGS Tensor. > > "We've heard that a million monkeys at a million keyboards could produce > the Complete Works of Shakespeare; now, thanks to the Internet, we know > this is not true."Robert Wilensky, University of California To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Threaded X libraries
On Fri, 13 Aug 1999, Stephen Hocking-Senior Programmer PGS Tensor Perth wrote: > I'm attempting to build the X11 libs with the thread safety stuff (I beleive > Linux can already be built like this) and have discovered when linking that we > don't have the getpwnam_r & getpwuid_r functions in out libc_r. Is anyone > planning on adding these? > > > Stephen > See the archives - I think it has already come up at least once. Sander There is no love, no good, no happiness and no future - all these are just illusions. > It's all part of my plan to make SDL (Sam Lantinga's Simple Direct Media > Layer) work. It dies quite frequently when starting sound & graphics in some > of the test apps. I am suspicious that it requires a threadsafe libX11. > -- > The views expressed above are not those of PGS Tensor. > > "We've heard that a million monkeys at a million keyboards could produce > the Complete Works of Shakespeare; now, thanks to the Internet, we know > this is not true."Robert Wilensky, University of California To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
