Re: building thread-safe Xlibs
Francis Jordan wrote: > > Can anyone please give me some clues as to how to build X with thread support > enabled. I think the right way to do it is to add the relevant options to > config/cf/FreeBSD.cf, something like > > #define HasPosixThreads YES > #define ThreadedX YES > #define ThreadsLibraries-pthread /* (or should it be -lc_r ? */ > #define SystemMTDefines -D_REENTRANT /* required ??? */ > #define HasThreadSafeAPINO > ^^ > - > > Here's the thing - FreeBSD doesn't seem to have thread-safe interfaces for > functions like getpwnam, getpwuid, getpwent (Solaris has getpwnam_r, > getpwuid_r, getpwent_r), hence lots of unresolved references. Then there's > the file > > xc/include/Xos_r.h > > which contains definitions of same (basically, pwd.h wrappers) for various > platforms, but not FreeBSD (I guess at the time FreeBSD didn't have threads). > Unfortunately, the wrappers for other platforms are no good, as FreeBSD's pwd > structures are different from everything else. > > If anyone has gotten the darn thing to compile, could you please send me the > relevant patches? Alternatively, is anyone looking into implementing the _r > API for getpwent? Yes, but I've been putting the getpwent_r routines off until last because they are going to be nasty. Locking access to a dbm database doesn't look good, so we may have to change to the newlib version of dbm in order to support them. This probably wouldn't happen until 4.0, and I'd have to come up with a binary file coverter, unless the newlib version already does that. Ick! ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: building thread-safe Xlibs
Francis Jordan wrote: > > Can anyone please give me some clues as to how to build X with thread support > enabled. I think the right way to do it is to add the relevant options to > config/cf/FreeBSD.cf, something like > > #define HasPosixThreads YES > #define ThreadedX YES > #define ThreadsLibraries-pthread /* (or should it be -lc_r ? */ > #define SystemMTDefines -D_REENTRANT /* required ??? */ > #define HasThreadSafeAPINO > ^^ > - > > Here's the thing - FreeBSD doesn't seem to have thread-safe interfaces for > functions like getpwnam, getpwuid, getpwent (Solaris has getpwnam_r, > getpwuid_r, getpwent_r), hence lots of unresolved references. Then there's > the file > > xc/include/Xos_r.h > > which contains definitions of same (basically, pwd.h wrappers) for various > platforms, but not FreeBSD (I guess at the time FreeBSD didn't have threads). > Unfortunately, the wrappers for other platforms are no good, as FreeBSD's pwd > structures are different from everything else. > > If anyone has gotten the darn thing to compile, could you please send me the > relevant patches? Alternatively, is anyone looking into implementing the _r > API for getpwent? Yes, but I've been putting the getpwent_r routines off until last because they are going to be nasty. Locking access to a dbm database doesn't look good, so we may have to change to the newlib version of dbm in order to support them. This probably wouldn't happen until 4.0, and I'd have to come up with a binary file coverter, unless the newlib version already does that. Ick! ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr w...@softweyr.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: [Re: coarse vs fine-grained locking in SMP systems]
Jesus Monroy wrote: > > Ville-Pertti Keinonen <[EMAIL PROTECTED]> wrote: > > [EMAIL PROTECTED] (Mike O'Dell) writes: > > > we published the best Unix SMP paper I've ever seen in Computing > > > Systems - from the Amdahl guys who did an SMP version of the kernel > > > by very clever hacks on SPLx() macros to make them spin locks and > > > a bit of other clever trickery on the source. they could take a stock > > > > An approach like that can't possibly be sufficient if code has been > > written with the assumption that only interrupt-like events or > > blocking calls can change things from under it. There is quite a bit > > of code in FreeBSD that relies on this. > > >Can you elaborate on this a bit more? I think I missing >some of the finer points on what you are saying. > >I work on interrupt driven device drivers and I'm trying >to see how this ties in. Here's a good example. It's from a different system that uses a modified BSD TCP/IP stack, but the example still holds. This system keeps a linked list of network interfaces. A periodic timer callback goes through this list to handle timeout issues for the IP stack. The timer routine didn't bother to acquire the semaphore protecting the list of network interfaces. When we moved the code to an SMP system, it would occasionally (as in once or twice a year across the entire customer base) crash with a null pointer in the list of network interfaces. The timer routine was being preempted by a higher-prioty user interface task removing a network interface. The timer would run off an invalid pointer and crash the system. This never happened on the single-processor system because the timer ran in timer context, which is not interruptable by a normal process regardless of the priority, but had failed to protect itself from a normal process on the other CPU. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [Re: coarse vs fine-grained locking in SMP systems]
Jesus Monroy wrote: > > Ville-Pertti Keinonen wrote: > > m...@servo.ccr.org (Mike O'Dell) writes: > > > we published the best Unix SMP paper I've ever seen in Computing > > > Systems - from the Amdahl guys who did an SMP version of the kernel > > > by very clever hacks on SPLx() macros to make them spin locks and > > > a bit of other clever trickery on the source. they could take a stock > > > > An approach like that can't possibly be sufficient if code has been > > written with the assumption that only interrupt-like events or > > blocking calls can change things from under it. There is quite a bit > > of code in FreeBSD that relies on this. > > >Can you elaborate on this a bit more? I think I missing >some of the finer points on what you are saying. > >I work on interrupt driven device drivers and I'm trying >to see how this ties in. Here's a good example. It's from a different system that uses a modified BSD TCP/IP stack, but the example still holds. This system keeps a linked list of network interfaces. A periodic timer callback goes through this list to handle timeout issues for the IP stack. The timer routine didn't bother to acquire the semaphore protecting the list of network interfaces. When we moved the code to an SMP system, it would occasionally (as in once or twice a year across the entire customer base) crash with a null pointer in the list of network interfaces. The timer routine was being preempted by a higher-prioty user interface task removing a network interface. The timer would run off an invalid pointer and crash the system. This never happened on the single-processor system because the timer ran in timer context, which is not interruptable by a normal process regardless of the priority, but had failed to protect itself from a normal process on the other CPU. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr w...@softweyr.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Implementation of mmap() in FreeBSD
This is how mmap() is supposed to work. mmap() may return an area larger then the one you specified due to page-alignment considerations. It is not legal for you to write in an area which is outside the range you specified, but there is no way for the machine to enforce this except on page boundries. Any writes you do within the page boundry, but outside the range you specified in the mmap() call, but inside the bounds of the file, will probably end up in the file. -Matt :>From the source code of mmap(), it seems to me that FreeBSD can not handle :mmap() when the specified file range [offset, offset + length] does not :align with memory page boundary. The mmap() automatically enlarges the :mapped area on BOTH ends of the given range to a page boundary. In the :following figure, the two X areas are not specified by the user, they are :included because we do rounding on both ends. : : +---+--+-+-+ : | X | | | X | : +---+--+-+-+ : ^ ^ ^ : | | | : page boundary page boundary page boundary : :Then a problem is what will happen if I read/write at the areas marked as :X? What will happen if I write into the area marked by the right X and :that area lies beyond the end of the file? According to the book by :W. Richard Stevens, if we write to the area marked by the right X, the :changes should not be reflected in the file (or expand the file). :... : :All these situations seem to me are not handled by FreeBSD mmap() code. I :hope I am wrong. I also wonder why we can not add some information to the No machine's mmap() code handles these situations. It is a side effect of the way MMU's work and the way mmap() was defined - that is, in order for mmap() to be reasonably optimal it has to munge the boundry conditions. It is an explicitly allowed case. :Any help or hint is appreciated. : :-- :Zhihui Zhang. Please visit http://www.freebsd.org :-- -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Implementation of mmap() in FreeBSD
This is how mmap() is supposed to work. mmap() may return an area larger then the one you specified due to page-alignment considerations. It is not legal for you to write in an area which is outside the range you specified, but there is no way for the machine to enforce this except on page boundries. Any writes you do within the page boundry, but outside the range you specified in the mmap() call, but inside the bounds of the file, will probably end up in the file. -Matt :>From the source code of mmap(), it seems to me that FreeBSD can not handle :mmap() when the specified file range [offset, offset + length] does not :align with memory page boundary. The mmap() automatically enlarges the :mapped area on BOTH ends of the given range to a page boundary. In the :following figure, the two X areas are not specified by the user, they are :included because we do rounding on both ends. : : +---+--+-+-+ : | X | | | X | : +---+--+-+-+ : ^ ^ ^ : | | | : page boundary page boundary page boundary : :Then a problem is what will happen if I read/write at the areas marked as :X? What will happen if I write into the area marked by the right X and :that area lies beyond the end of the file? According to the book by :W. Richard Stevens, if we write to the area marked by the right X, the :changes should not be reflected in the file (or expand the file). :... : :All these situations seem to me are not handled by FreeBSD mmap() code. I :hope I am wrong. I also wonder why we can not add some information to the No machine's mmap() code handles these situations. It is a side effect of the way MMU's work and the way mmap() was defined - that is, in order for mmap() to be reasonably optimal it has to munge the boundry conditions. It is an explicitly allowed case. :Any help or hint is appreciated. : :-- :Zhihui Zhang. Please visit http://www.freebsd.org :-- -Matt Matthew Dillon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Simplifying Vinum (was: ufs/ffs resize?)
On Friday, 25 June 1999 at 23:53:50 -0700, Jordan K. Hubbard wrote: >> I agree with the approach. But why write a simplistic volume manager >> when we already have vinum? > > vinum is far from simplistic, but I suppose it might also do. :) > > Still, it would someday be nice if you could use vinum as the very > powerful swiss-army knife that it currently is OR as a dull axe to > simply concatenate, ala ccd, n partitions together in some extremely > straight-forward fashion. That is to say, instead of having to think > about subdisks on plexes on foxes on clockses (sorry Dr. Seuss) when all > you wanted to do is whack some space together in a simple and obvious way, > you could say something like "vinum -C /dev/wd0s1a /dev/sd1s2 /dev/sd2" > in order to concatenate wd0/slice 1/partition a, sd1/all of slice 2, > and all of drive sd2 together. vinum would choose the volume name itself > and return it, from this it being possible to contrive the device pathname > for newfs and mount. Well, that's an interesting viewpoint. It's not Vinum, of course, that we need to change, just the control program. > One might then logically assume the next step would be trivial insertion > and deletion options, like: > >vinum -i /dev/something volumename > > to insert a new partition into existing volume volumename and > >vinum -d /dev/something volumename > > to delete /dev/something from volumename, assuming that it's found > in that volume. I guess while I'm dreaming, you could use -M to > also create trivial mirror sets and -i and -d could act on those > as well. :) I think you'll find, once you get that far, that things are anything but trivial. I'm certainly open to suggestions, but consider: vinum -i /dev/something volumename Where does it insert it? What if the volume has more than one plex, which it will in the case of a mirror? I'm not saying that this can't be done, but one of the reasons for the relatively formal way that Vinum does things is precisely to make it more difficult to make misassumptions. > Lest anyone get the wrong idea, let me also hastily note here that I'm > not trying to suggest that vinum should shed functionality or become > dumbed-down - the current amount of flexibility is good and probably > in full accord with "the unix way" insofar as I understand vinum's > operation. :) Yes, I think I understand that relatively well. > It's also more than a little indimidating to new users, however, > many of whom only want to use it for the most simplistic scenarios > anyway. Some big dials to go with all the small dials can't hurt, > can it? :) Not if they're done well. I'm open to suggestions. Here are couple of possibilities: add commands "cat", "stripe" and "mirror": vinum cat /dev/da1h /dev/da2h vinum stripe /dev/da1h /dev/da2h /dev/da3h /dev/da4h vinum mirror /dev/da1h /dev/da2h vinum mirror /dev/da1h /dev/da2h /dev/da3h /dev/da4h The first one would take the drives and create a concatenated volume out of them. The second would do the same thing but make a striped volume. The third would make a simple concatenated mirror, and the fourth... yes, what about the fourth? Four plexes, each of one volume? Two plexes, each concatenating two drives? You tell me. And what about the names? It seems tacky to have to write down the name that Vinum chooses. How about adding a name parameter, either implicitly or explicitly? For example, vinum cat myvol /dev/da1h /dev/da2h vinum cat -n myvol /dev/da1h /dev/da2h Greg -- See complete headers for address, home page and phone numbers finger [EMAIL PROTECTED] for PGP public key To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Simplifying Vinum (was: ufs/ffs resize?)
On Friday, 25 June 1999 at 23:53:50 -0700, Jordan K. Hubbard wrote: >> I agree with the approach. But why write a simplistic volume manager >> when we already have vinum? > > vinum is far from simplistic, but I suppose it might also do. :) > > Still, it would someday be nice if you could use vinum as the very > powerful swiss-army knife that it currently is OR as a dull axe to > simply concatenate, ala ccd, n partitions together in some extremely > straight-forward fashion. That is to say, instead of having to think > about subdisks on plexes on foxes on clockses (sorry Dr. Seuss) when all > you wanted to do is whack some space together in a simple and obvious way, > you could say something like "vinum -C /dev/wd0s1a /dev/sd1s2 /dev/sd2" > in order to concatenate wd0/slice 1/partition a, sd1/all of slice 2, > and all of drive sd2 together. vinum would choose the volume name itself > and return it, from this it being possible to contrive the device pathname > for newfs and mount. Well, that's an interesting viewpoint. It's not Vinum, of course, that we need to change, just the control program. > One might then logically assume the next step would be trivial insertion > and deletion options, like: > >vinum -i /dev/something volumename > > to insert a new partition into existing volume volumename and > >vinum -d /dev/something volumename > > to delete /dev/something from volumename, assuming that it's found > in that volume. I guess while I'm dreaming, you could use -M to > also create trivial mirror sets and -i and -d could act on those > as well. :) I think you'll find, once you get that far, that things are anything but trivial. I'm certainly open to suggestions, but consider: vinum -i /dev/something volumename Where does it insert it? What if the volume has more than one plex, which it will in the case of a mirror? I'm not saying that this can't be done, but one of the reasons for the relatively formal way that Vinum does things is precisely to make it more difficult to make misassumptions. > Lest anyone get the wrong idea, let me also hastily note here that I'm > not trying to suggest that vinum should shed functionality or become > dumbed-down - the current amount of flexibility is good and probably > in full accord with "the unix way" insofar as I understand vinum's > operation. :) Yes, I think I understand that relatively well. > It's also more than a little indimidating to new users, however, > many of whom only want to use it for the most simplistic scenarios > anyway. Some big dials to go with all the small dials can't hurt, > can it? :) Not if they're done well. I'm open to suggestions. Here are couple of possibilities: add commands "cat", "stripe" and "mirror": vinum cat /dev/da1h /dev/da2h vinum stripe /dev/da1h /dev/da2h /dev/da3h /dev/da4h vinum mirror /dev/da1h /dev/da2h vinum mirror /dev/da1h /dev/da2h /dev/da3h /dev/da4h The first one would take the drives and create a concatenated volume out of them. The second would do the same thing but make a striped volume. The third would make a simple concatenated mirror, and the fourth... yes, what about the fourth? Four plexes, each of one volume? Two plexes, each concatenating two drives? You tell me. And what about the names? It seems tacky to have to write down the name that Vinum chooses. How about adding a name parameter, either implicitly or explicitly? For example, vinum cat myvol /dev/da1h /dev/da2h vinum cat -n myvol /dev/da1h /dev/da2h Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Implementation of mmap() in FreeBSD
>From the source code of mmap(), it seems to me that FreeBSD can not handle mmap() when the specified file range [offset, offset + length] does not align with memory page boundary. The mmap() automatically enlarges the mapped area on BOTH ends of the given range to a page boundary. In the following figure, the two X areas are not specified by the user, they are included because we do rounding on both ends. +---+--+-+-+ | X | | | X | +---+--+-+-+ ^ ^ ^ | | | page boundary page boundary page boundary Then a problem is what will happen if I read/write at the areas marked as X? What will happen if I write into the area marked by the right X and that area lies beyond the end of the file? According to the book by W. Richard Stevens, if we write to the area marked by the right X, the changes should not be reflected in the file (or expand the file). All these situations seem to me are not handled by FreeBSD mmap() code. I hope I am wrong. I also wonder why we can not add some information to the backing object, so that we can handle these situations. If these problems do exist, how hard it is to fix them? Any help or hint is appreciated. -- 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
Implementation of mmap() in FreeBSD
Re: Microsoft performance (was: ...)
In message <[EMAIL PROTECTED]> Matthew Hunt writes: : Security holes are rarely in the kernel, and you can easily keep your : applications up-to-date without rebooting. And the ones that re in the kernel tend to be DoS type problems that force a reboot anyway :-( Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
In message <19990624114734.a96...@wopr.caltech.edu> Matthew Hunt writes: : Security holes are rarely in the kernel, and you can easily keep your : applications up-to-date without rebooting. And the ones that re in the kernel tend to be DoS type problems that force a reboot anyway :-( Warner To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Volume managers (was: ufs/ffs resize?)
On Sun, Jun 27, 1999 at 09:33:45AM +0930, Greg Lehey wrote: > On Sunday, 27 June 1999 at 0:35:54 +0200, Ollivier Robert wrote: > > According to Bernd Walter: > >> I wrote one. > >> It is place on ftp://ftp.cosmo-project.de/pub/growfs > >> My tool will grow a UFS filesystem to the current size of the partition. > > > > Another datapoint ot consider, it seems that Linux (at least the > > derivative version maintained by Alan Cox -- the other one :) ) has > > now grown an LVM system (probably à la HP or AIX). That's what I've > > been told yesterday during a small conference about Linux and free > > software in France (and where I did a talk about FreeBSD *grin*). > > Interesting. If you find any pointers, I'd like to take a look. http://linux.msede.com/lvm/ -- Regards, Norman C. Rice, Jr. > Looks like this is a case where Linux is following FreeBSD :-) > > > I think one of the difficulty of growing a FS is that you have to > > choose whether you need the FS to be contiguous or not. The latter > > case makes it much more difficult... > > Why shouldn't it be contiguous? That's what the volume manager's > there for. > > Greg > -- > See complete headers for address, home page and phone numbers > finger [EMAIL PROTECTED] for PGP public key To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Volume managers (was: ufs/ffs resize?)
On Sun, Jun 27, 1999 at 09:33:45AM +0930, Greg Lehey wrote: > On Sunday, 27 June 1999 at 0:35:54 +0200, Ollivier Robert wrote: > > According to Bernd Walter: > >> I wrote one. > >> It is place on ftp://ftp.cosmo-project.de/pub/growfs > >> My tool will grow a UFS filesystem to the current size of the partition. > > > > Another datapoint ot consider, it seems that Linux (at least the > > derivative version maintained by Alan Cox -- the other one :) ) has > > now grown an LVM system (probably à la HP or AIX). That's what I've > > been told yesterday during a small conference about Linux and free > > software in France (and where I did a talk about FreeBSD *grin*). > > Interesting. If you find any pointers, I'd like to take a look. http://linux.msede.com/lvm/ -- Regards, Norman C. Rice, Jr. > Looks like this is a case where Linux is following FreeBSD :-) > > > I think one of the difficulty of growing a FS is that you have to > > choose whether you need the FS to be contiguous or not. The latter > > case makes it much more difficult... > > Why shouldn't it be contiguous? That's what the volume manager's > there for. > > Greg > -- > See complete headers for address, home page and phone numbers > finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: ufs/ffs resize?
On Sun, Jun 27, 1999 at 12:35:54AM +0200, Ollivier Robert wrote: > > Another datapoint ot consider, it seems that Linux (at least the derivative > version maintained by Alan Cox -- the other one :) ) has now grown an LVM > system (probably à la HP or AIX). That's what I've been told yesterday during > a small conference about Linux and free software in France (and where I did a > talk about FreeBSD *grin*). Hmmm. It might be from SGI. SGI has donated XFS to Linux and is actively marketing it on their Intel based systems. http://www.news.com/News/Item/0,4,36807,00.html?st.ne.fd.tohhed.ni Regards, --Keith Stevenson-- -- Keith Stevenson System Programmer - Data Center Services - University of Louisville [EMAIL PROTECTED] PGP key fingerprint = 4B 29 A8 95 A8 82 EA A2 29 CE 68 DE FC EE B6 A0 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ufs/ffs resize?
On Sun, Jun 27, 1999 at 12:35:54AM +0200, Ollivier Robert wrote: > > Another datapoint ot consider, it seems that Linux (at least the derivative > version maintained by Alan Cox -- the other one :) ) has now grown an LVM > system (probably à la HP or AIX). That's what I've been told yesterday during > a small conference about Linux and free software in France (and where I did a > talk about FreeBSD *grin*). Hmmm. It might be from SGI. SGI has donated XFS to Linux and is actively marketing it on their Intel based systems. http://www.news.com/News/Item/0,4,36807,00.html?st.ne.fd.tohhed.ni Regards, --Keith Stevenson-- -- Keith Stevenson System Programmer - Data Center Services - University of Louisville k.steven...@louisville.edu PGP key fingerprint = 4B 29 A8 95 A8 82 EA A2 29 CE 68 DE FC EE B6 A0 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Volume managers (was: ufs/ffs resize?)
On Sunday, 27 June 1999 at 0:35:54 +0200, Ollivier Robert wrote: > According to Bernd Walter: >> I wrote one. >> It is place on ftp://ftp.cosmo-project.de/pub/growfs >> My tool will grow a UFS filesystem to the current size of the partition. > > Another datapoint ot consider, it seems that Linux (at least the > derivative version maintained by Alan Cox -- the other one :) ) has > now grown an LVM system (probably à la HP or AIX). That's what I've > been told yesterday during a small conference about Linux and free > software in France (and where I did a talk about FreeBSD *grin*). Interesting. If you find any pointers, I'd like to take a look. Looks like this is a case where Linux is following FreeBSD :-) > I think one of the difficulty of growing a FS is that you have to > choose whether you need the FS to be contiguous or not. The latter > case makes it much more difficult... Why shouldn't it be contiguous? That's what the volume manager's there for. Greg -- See complete headers for address, home page and phone numbers finger [EMAIL PROTECTED] for PGP public key To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Volume managers (was: ufs/ffs resize?)
On Sunday, 27 June 1999 at 0:35:54 +0200, Ollivier Robert wrote: > According to Bernd Walter: >> I wrote one. >> It is place on ftp://ftp.cosmo-project.de/pub/growfs >> My tool will grow a UFS filesystem to the current size of the partition. > > Another datapoint ot consider, it seems that Linux (at least the > derivative version maintained by Alan Cox -- the other one :) ) has > now grown an LVM system (probably à la HP or AIX). That's what I've > been told yesterday during a small conference about Linux and free > software in France (and where I did a talk about FreeBSD *grin*). Interesting. If you find any pointers, I'd like to take a look. Looks like this is a case where Linux is following FreeBSD :-) > I think one of the difficulty of growing a FS is that you have to > choose whether you need the FS to be contiguous or not. The latter > case makes it much more difficult... Why shouldn't it be contiguous? That's what the volume manager's there for. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
All this and documentation too? (was: Microsoft performance (was: All this and documentation too? (was: cvs commit: src/sys/isa sio.c)))
On Saturday, 26 June 1999 at 12:03:59 -0500, Constantine Shkolny wrote: > On Saturday, June 26, 1999 8:08 AM, Nick Hibma [SMTP:[EMAIL PROTECTED]] > wrote: >>> Programmers need documentation too. >> >> And they are going to scream like mad if there isn't any. But in the end >> they start reading the code anyway, even if there is docu, because they >> don't trust anything but their own eyes and brain. >> >> It's all documented in C anyway. > > I've come to understanding that lack of documentation is probably one of > the factors that keep the system healthy, because it keeps the unskilled > people away. I don't know whether it's true but I read in books that > reading code is one of the methods to learn programming. Since FreeBSD > does ship with source code, docs are not necessary. NT ships with poorly > written docs instead, and, that is what kills it all the time, despite of > its perfect design that I really like. People write NT drivers without > full understanding what is going on, so they destabilize the system. I can't agree with this theory. Lack of documentation just moves the degree of skill needed to, for example, write device drivers. Document less well and your average device driver writer will write a worse driver, with or without source code access. Source code access helps too, of course. Greg -- See complete headers for address, home page and phone numbers finger [EMAIL PROTECTED] for PGP public key To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
All this and documentation too? (was: Microsoft performance (was: All this and documentation too? (was: cvs commit: src/sys/isa sio.c)))
On Saturday, 26 June 1999 at 12:03:59 -0500, Constantine Shkolny wrote: > On Saturday, June 26, 1999 8:08 AM, Nick Hibma [SMTP:hi...@skylink.it] > wrote: >>> Programmers need documentation too. >> >> And they are going to scream like mad if there isn't any. But in the end >> they start reading the code anyway, even if there is docu, because they >> don't trust anything but their own eyes and brain. >> >> It's all documented in C anyway. > > I've come to understanding that lack of documentation is probably one of > the factors that keep the system healthy, because it keeps the unskilled > people away. I don't know whether it's true but I read in books that > reading code is one of the methods to learn programming. Since FreeBSD > does ship with source code, docs are not necessary. NT ships with poorly > written docs instead, and, that is what kills it all the time, despite of > its perfect design that I really like. People write NT drivers without > full understanding what is going on, so they destabilize the system. I can't agree with this theory. Lack of documentation just moves the degree of skill needed to, for example, write device drivers. Document less well and your average device driver writer will write a worse driver, with or without source code access. Source code access helps too, of course. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: ufs/ffs resize?
According to Bernd Walter: > I wrote one. > It is place on ftp://ftp.cosmo-project.de/pub/growfs > My tool will grow a UFS filesystem to the current size of the partition. Another datapoint ot consider, it seems that Linux (at least the derivative version maintained by Alan Cox -- the other one :) ) has now grown an LVM system (probably à la HP or AIX). That's what I've been told yesterday during a small conference about Linux and free software in France (and where I did a talk about FreeBSD *grin*). I think one of the difficulty of growing a FS is that you have to choose whether you need the FS to be contiguous or not. The latter case makes it much more difficult... -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] FreeBSD keltia.freenix.fr 4.0-CURRENT #71: Sun May 9 20:16:32 CEST 1999 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ufs/ffs resize?
According to Bernd Walter: > I wrote one. > It is place on ftp://ftp.cosmo-project.de/pub/growfs > My tool will grow a UFS filesystem to the current size of the partition. Another datapoint ot consider, it seems that Linux (at least the derivative version maintained by Alan Cox -- the other one :) ) has now grown an LVM system (probably à la HP or AIX). That's what I've been told yesterday during a small conference about Linux and free software in France (and where I did a talk about FreeBSD *grin*). I think one of the difficulty of growing a FS is that you have to choose whether you need the FS to be contiguous or not. The latter case makes it much more difficult... -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #71: Sun May 9 20:16:32 CEST 1999 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: ufs/ffs resize?
On Fri, Jun 25, 1999 at 02:15:01PM -0700, Matthew Dillon wrote: > :anybody done any work on a utility for growing ufs filesystems? > : > :aaron > > It has been brought up a couple of times but nobody has tried > to do actually it. Personally, I think it would be a doable > project if someone wanted to have a go at it - to allow a filesystem > to be grown or shrunk on a cylinder-by-cylinder basis. The only real > complexity occurs when you are shrinking a filesystem - you have to locate > the inodes & indirect blocks associated with allocated data blocks > in the cylinder you are trying to remove in order to move the blocks. Thats a point you still have to do if you grow a fs - but you don't need to relocate inode but only data-blocks. That's because each cg has a summary information of some bytes which are duplicated at the beginning of the fs in the first cg. In some cases you will need one or more additional blocks in the first cg. unfortunately these are garantied to allocated in case of the first use for the /-dir. Depeneding on what Kirk McKusik wrote this summary information must be of full size. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ufs/ffs resize?
On Fri, Jun 25, 1999 at 02:15:01PM -0700, Matthew Dillon wrote: > :anybody done any work on a utility for growing ufs filesystems? > : > :aaron > > It has been brought up a couple of times but nobody has tried > to do actually it. Personally, I think it would be a doable > project if someone wanted to have a go at it - to allow a filesystem > to be grown or shrunk on a cylinder-by-cylinder basis. The only real > complexity occurs when you are shrinking a filesystem - you have to locate > the inodes & indirect blocks associated with allocated data blocks > in the cylinder you are trying to remove in order to move the blocks. Thats a point you still have to do if you grow a fs - but you don't need to relocate inode but only data-blocks. That's because each cg has a summary information of some bytes which are duplicated at the beginning of the fs in the first cg. In some cases you will need one or more additional blocks in the first cg. unfortunately these are garantied to allocated in case of the first use for the /-dir. Depeneding on what Kirk McKusik wrote this summary information must be of full size. -- B.Walter COSMO-Project http://www.cosmo-project.de ti...@cicely.de i...@cosmo-project.de To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: ufs/ffs resize?
On Fri, Jun 25, 1999 at 02:00:41PM -0700, Aaron Smith wrote: > anybody done any work on a utility for growing ufs filesystems? > I wrote one. It is place on ftp://ftp.cosmo-project.de/pub/growfs My tool will grow a UFS filesystem to the current size of the partition. There is still one big problem left when the number of cylindergroups went over a usually 512 align. I hope to free enough time during the next weeks to remove some blocks and add some warnings in this case. With this problem you should check manualy for that condition because it will break the fs in such cases. All bugs should have been documented in the man-page. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ufs/ffs resize?
On Fri, Jun 25, 1999 at 02:00:41PM -0700, Aaron Smith wrote: > anybody done any work on a utility for growing ufs filesystems? > I wrote one. It is place on ftp://ftp.cosmo-project.de/pub/growfs My tool will grow a UFS filesystem to the current size of the partition. There is still one big problem left when the number of cylindergroups went over a usually 512 align. I hope to free enough time during the next weeks to remove some blocks and add some warnings in this case. With this problem you should check manualy for that condition because it will break the fs in such cases. All bugs should have been documented in the man-page. -- B.Walter COSMO-Project http://www.cosmo-project.de ti...@cicely.de i...@cosmo-project.de To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
As Matthew Jacob wrote ... > > > On Sat, 26 Jun 1999, Wilko Bulte wrote: > > > As Matthew Jacob wrote ... > > > > > > Yes, you want the WWN to stay constant. That doesn't mean it should > > > necessarily be the same physical box. Nor does it mean it should be a > > > system that comes with a WWN assigned to by the manufacturer. > > > > Manufacturers have to register and 'get' a unique range they can assign > > to their products. How do you guarantee that your homegrown WWN is > > really unique? > > Witha a value in the top 4 bits that's not one of the currently defined > authoritative values. Not waterproof, at least to WW unique. What stops me from inventing exactly the same WWN as you do for your machine? Playing the devils (daemon's?) advocate, I admit.. > > > And to boot a Sun over fibre channel, you use the WWN. > > > > Well, we currently don't support that, but indeed that is what you would > > do. Tru64 Unix does something similar. > > > You can boot off of fibre channel now- but not using a WWN. Well, "we" is Compaq using a HSG80 FC raidbox on a Sun with a Jaycor adapter in the Sun. -- | / o / / _ Arnhem, The Netherlands- Powered by FreeBSD - |/|/ / / /( (_) BulteWWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
As Matthew Jacob wrote ... > > > On Sat, 26 Jun 1999, Wilko Bulte wrote: > > > As Matthew Jacob wrote ... > > > > > > Yes, you want the WWN to stay constant. That doesn't mean it should > > > necessarily be the same physical box. Nor does it mean it should be a > > > system that comes with a WWN assigned to by the manufacturer. > > > > Manufacturers have to register and 'get' a unique range they can assign > > to their products. How do you guarantee that your homegrown WWN is > > really unique? > > Witha a value in the top 4 bits that's not one of the currently defined > authoritative values. Not waterproof, at least to WW unique. What stops me from inventing exactly the same WWN as you do for your machine? Playing the devils (daemon's?) advocate, I admit.. > > > And to boot a Sun over fibre channel, you use the WWN. > > > > Well, we currently don't support that, but indeed that is what you would > > do. Tru64 Unix does something similar. > > > You can boot off of fibre channel now- but not using a WWN. Well, "we" is Compaq using a HSG80 FC raidbox on a Sun with a Jaycor adapter in the Sun. -- | / o / / _ Arnhem, The Netherlands- Powered by FreeBSD - |/|/ / / /( (_) BulteWWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
RE: Microsoft performance (was: All this and documentation too? (was: cvs commit: src/sys/isa sio.c))
On Saturday, June 26, 1999 8:08 AM, Nick Hibma [SMTP:[EMAIL PROTECTED]] wrote: > > Programmers need documentation too. > > And they are going to scream like mad if there isn't any. But in the end > they start reading the code anyway, even if there is docu, because they > don't trust anything but their own eyes and brain. > > It's all documented in C anyway. I've come to understanding that lack of documentation is probably one of the factors that keep the system healthy, because it keeps the unskilled people away. I don't know whether it's true but I read in books that reading code is one of the methods to learn programming. Since FreeBSD does ship with source code, docs are not necessary. NT ships with poorly written docs instead, and, that is what kills it all the time, despite of its perfect design that I really like. People write NT drivers without full understanding what is going on, so they destabilize the system. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Microsoft performance (was: All this and documentation too? (was: cvs commit: src/sys/isa sio.c))
On Saturday, June 26, 1999 8:08 AM, Nick Hibma [SMTP:hi...@skylink.it] wrote: > > Programmers need documentation too. > > And they are going to scream like mad if there isn't any. But in the end > they start reading the code anyway, even if there is docu, because they > don't trust anything but their own eyes and brain. > > It's all documented in C anyway. I've come to understanding that lack of documentation is probably one of the factors that keep the system healthy, because it keeps the unskilled people away. I don't know whether it's true but I read in books that reading code is one of the methods to learn programming. Since FreeBSD does ship with source code, docs are not necessary. NT ships with poorly written docs instead, and, that is what kills it all the time, despite of its perfect design that I really like. People write NT drivers without full understanding what is going on, so they destabilize the system. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
No Subject
[no subject]
Re: System unique identifier.....
On Sat, 26 Jun 1999, Wilko Bulte wrote: > As Matthew Jacob wrote ... > > > > Yes, you want the WWN to stay constant. That doesn't mean it should > > necessarily be the same physical box. Nor does it mean it should be a > > system that comes with a WWN assigned to by the manufacturer. > > Manufacturers have to register and 'get' a unique range they can assign > to their products. How do you guarantee that your homegrown WWN is > really unique? Witha a value in the top 4 bits that's not one of the currently defined authoritative values. > > > I think I'm confusing myself and people. I have a WWN. By definition it > > should be unique value. All I'm asking for is a kernel function to help me > > generate such a thing (despite what Eduardo says). > > > > > > On Fri, 25 Jun 1999, Wilko Bulte wrote: > > > > > As Matthew Jacob wrote ... > > > > > > > > > > FYI: The Compaq HSG80 Fibrechannel RAID controllers have their > > > > > WWN in NVRAM. One is supposed to get the WWN from a label on the *cabinet* > > > > > into the HSG controller. This allows for easy hardware swap in case of > > > > > hardware grief. > > > > > > > > Yes, if you want the WWN to stay constant. > > > > > > Well, you do. Especially when you are using things like zoning (like > > > that Brocade switches can do) or when the host directly ties things to > > > the wwn it talks to. E.g. for connection to Sun we use Jaycor adapters > > > that allow things like "target=foo lun=bar www="<64bitnumber>" in the > > > Solaris /kernel/drv/sd.conf file > > > > And to boot a Sun over fibre channel, you use the WWN. > > Well, we currently don't support that, but indeed that is what you would > do. Tru64 Unix does something similar. You can boot off of fibre channel now- but not using a WWN. I want to see devfs fixed and using WWWs and/or device VPD. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
On Sat, 26 Jun 1999, Wilko Bulte wrote: > As Matthew Jacob wrote ... > > > > Yes, you want the WWN to stay constant. That doesn't mean it should > > necessarily be the same physical box. Nor does it mean it should be a > > system that comes with a WWN assigned to by the manufacturer. > > Manufacturers have to register and 'get' a unique range they can assign > to their products. How do you guarantee that your homegrown WWN is > really unique? Witha a value in the top 4 bits that's not one of the currently defined authoritative values. > > > I think I'm confusing myself and people. I have a WWN. By definition it > > should be unique value. All I'm asking for is a kernel function to help me > > generate such a thing (despite what Eduardo says). > > > > > > On Fri, 25 Jun 1999, Wilko Bulte wrote: > > > > > As Matthew Jacob wrote ... > > > > > > > > > > FYI: The Compaq HSG80 Fibrechannel RAID controllers have their > > > > > WWN in NVRAM. One is supposed to get the WWN from a label on the > > > > > *cabinet* > > > > > into the HSG controller. This allows for easy hardware swap in case of > > > > > hardware grief. > > > > > > > > Yes, if you want the WWN to stay constant. > > > > > > Well, you do. Especially when you are using things like zoning (like > > > that Brocade switches can do) or when the host directly ties things to > > > the wwn it talks to. E.g. for connection to Sun we use Jaycor adapters > > > that allow things like "target=foo lun=bar www="<64bitnumber>" in the > > > Solaris /kernel/drv/sd.conf file > > > > And to boot a Sun over fibre channel, you use the WWN. > > Well, we currently don't support that, but indeed that is what you would > do. Tru64 Unix does something similar. You can boot off of fibre channel now- but not using a WWN. I want to see devfs fixed and using WWWs and/or device VPD. -matt To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
As Matthew Jacob wrote ... > > Yes, you want the WWN to stay constant. That doesn't mean it should > necessarily be the same physical box. Nor does it mean it should be a > system that comes with a WWN assigned to by the manufacturer. Manufacturers have to register and 'get' a unique range they can assign to their products. How do you guarantee that your homegrown WWN is really unique? > I think I'm confusing myself and people. I have a WWN. By definition it > should be unique value. All I'm asking for is a kernel function to help me > generate such a thing (despite what Eduardo says). > > > On Fri, 25 Jun 1999, Wilko Bulte wrote: > > > As Matthew Jacob wrote ... > > > > > > > > FYI: The Compaq HSG80 Fibrechannel RAID controllers have their > > > > WWN in NVRAM. One is supposed to get the WWN from a label on the *cabinet* > > > > into the HSG controller. This allows for easy hardware swap in case of > > > > hardware grief. > > > > > > Yes, if you want the WWN to stay constant. > > > > Well, you do. Especially when you are using things like zoning (like > > that Brocade switches can do) or when the host directly ties things to > > the wwn it talks to. E.g. for connection to Sun we use Jaycor adapters > > that allow things like "target=foo lun=bar www="<64bitnumber>" in the > > Solaris /kernel/drv/sd.conf file > > And to boot a Sun over fibre channel, you use the WWN. Well, we currently don't support that, but indeed that is what you would do. Tru64 Unix does something similar. -- | / o / / _ Arnhem, The Netherlands- Powered by FreeBSD - |/|/ / / /( (_) BulteWWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
panic in 3.2-STABLE / any clues?
I left my system to do a make release only to find that it had rebooted while doing the make: There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"... (no debugging symbols found)... IdlePTD 3141632 initial pcb at 28e4f4 panicstr: page fault panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01fbe13 stack pointer = 0x10:0xc6bd5d58 frame pointer = 0x10:0xc6bd5d58 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 92105 (awk) interrupt mask = trap number = 12 panic: page fault syncing disks... 81 79 74 68 51 38 24 1 done dumping to dev 30401, offset 327680 dump 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 --- #0 0xc0159437 in boot () (kgdb) bt #0 0xc0159437 in boot () #1 0xc01596bc in at_shutdown () #2 0xc021ca85 in trap_fatal () #3 0xc021c763 in trap_pfault () #4 0xc021c406 in trap () #5 0xc01fbe13 in vm_map_entry_create () #6 0xc01fc93e in _vm_map_clip_end () #7 0xc01fdc9b in vm_map_delete () #8 0xc01fde51 in vm_map_remove () #9 0xc01ffc79 in vm_mmap () #10 0xc01ff4d1 in mmap () #11 0xc021ccc7 in syscall () #12 0xc0213abc in Xint0x80_syscall () #13 0x180680ae in ?? () #14 0x18066fa2 in ?? () #15 0x18066e7a in ?? () #16 0x18066268 in ?? () (kgdb) # uname -a FreeBSD yedi.iaf.nl 3.2-STABLE FreeBSD 3.2-STABLE #3: Sun Jun 20 19:18:26 CEST 1999 [EMAIL PROTECTED]:/usr/freebsd-3.1-stable-src/src/sys/compile/YEDI i386 Any obvious clues? Wilko -- | / o / / _ Arnhem, The Netherlands- Powered by FreeBSD - |/|/ / / /( (_) BulteWWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
panic in 3.2-STABLE / any clues?
I left my system to do a make release only to find that it had rebooted while doing the make: There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"... (no debugging symbols found)... IdlePTD 3141632 initial pcb at 28e4f4 panicstr: page fault panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01fbe13 stack pointer = 0x10:0xc6bd5d58 frame pointer = 0x10:0xc6bd5d58 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 92105 (awk) interrupt mask = trap number = 12 panic: page fault syncing disks... 81 79 74 68 51 38 24 1 done dumping to dev 30401, offset 327680 dump 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 --- #0 0xc0159437 in boot () (kgdb) bt #0 0xc0159437 in boot () #1 0xc01596bc in at_shutdown () #2 0xc021ca85 in trap_fatal () #3 0xc021c763 in trap_pfault () #4 0xc021c406 in trap () #5 0xc01fbe13 in vm_map_entry_create () #6 0xc01fc93e in _vm_map_clip_end () #7 0xc01fdc9b in vm_map_delete () #8 0xc01fde51 in vm_map_remove () #9 0xc01ffc79 in vm_mmap () #10 0xc01ff4d1 in mmap () #11 0xc021ccc7 in syscall () #12 0xc0213abc in Xint0x80_syscall () #13 0x180680ae in ?? () #14 0x18066fa2 in ?? () #15 0x18066e7a in ?? () #16 0x18066268 in ?? () (kgdb) # uname -a FreeBSD yedi.iaf.nl 3.2-STABLE FreeBSD 3.2-STABLE #3: Sun Jun 20 19:18:26 CEST 1999 r...@yedi.iaf.nl:/usr/freebsd-3.1-stable-src/src/sys/compile/YEDI i386 Any obvious clues? Wilko -- | / o / / _ Arnhem, The Netherlands- Powered by FreeBSD - |/|/ / / /( (_) BulteWWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
As Matthew Jacob wrote ... > > Yes, you want the WWN to stay constant. That doesn't mean it should > necessarily be the same physical box. Nor does it mean it should be a > system that comes with a WWN assigned to by the manufacturer. Manufacturers have to register and 'get' a unique range they can assign to their products. How do you guarantee that your homegrown WWN is really unique? > I think I'm confusing myself and people. I have a WWN. By definition it > should be unique value. All I'm asking for is a kernel function to help me > generate such a thing (despite what Eduardo says). > > > On Fri, 25 Jun 1999, Wilko Bulte wrote: > > > As Matthew Jacob wrote ... > > > > > > > > FYI: The Compaq HSG80 Fibrechannel RAID controllers have their > > > > WWN in NVRAM. One is supposed to get the WWN from a label on the > > > > *cabinet* > > > > into the HSG controller. This allows for easy hardware swap in case of > > > > hardware grief. > > > > > > Yes, if you want the WWN to stay constant. > > > > Well, you do. Especially when you are using things like zoning (like > > that Brocade switches can do) or when the host directly ties things to > > the wwn it talks to. E.g. for connection to Sun we use Jaycor adapters > > that allow things like "target=foo lun=bar www="<64bitnumber>" in the > > Solaris /kernel/drv/sd.conf file > > And to boot a Sun over fibre channel, you use the WWN. Well, we currently don't support that, but indeed that is what you would do. Tru64 Unix does something similar. -- | / o / / _ Arnhem, The Netherlands- Powered by FreeBSD - |/|/ / / /( (_) BulteWWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Inetd and wrapping.
On Sat, Jun 26, 1999 at 06:55:53AM +0200, Sheldon Hearn wrote: > > I don't think the core team would care enough about something this silly > to bother making a decision, so I'm just watching what people have to > say. I'm leaning toward leaving the "nowrap" feature out. FWIW, I think that leaving out the nowrap feature would be a very good idea. I'm willing to agree (somewhat grudgingly) that incorporating libwrap is a definite feature improvement, but this conf file change doesn't seem to buy much at all. If a user needs that level of granularity, they can disable libwrap support on the inetd command line and use tcpd. Regards, --Keith Stevenson-- -- Keith Stevenson System Programmer - Data Center Services - University of Louisville [EMAIL PROTECTED] PGP key fingerprint = 4B 29 A8 95 A8 82 EA A2 29 CE 68 DE FC EE B6 A0 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Inetd and wrapping.
On Sat, Jun 26, 1999 at 06:55:53AM +0200, Sheldon Hearn wrote: > > I don't think the core team would care enough about something this silly > to bother making a decision, so I'm just watching what people have to > say. I'm leaning toward leaving the "nowrap" feature out. FWIW, I think that leaving out the nowrap feature would be a very good idea. I'm willing to agree (somewhat grudgingly) that incorporating libwrap is a definite feature improvement, but this conf file change doesn't seem to buy much at all. If a user needs that level of granularity, they can disable libwrap support on the inetd command line and use tcpd. Regards, --Keith Stevenson-- -- Keith Stevenson System Programmer - Data Center Services - University of Louisville k.steven...@louisville.edu PGP key fingerprint = 4B 29 A8 95 A8 82 EA A2 29 CE 68 DE FC EE B6 A0 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: All this and documentation too? (was: cvs commit: src/sys/isa sio.c))
On Sat, Jun 26, 1999 at 03:08:10PM +0200, Nick Hibma wrote: > > And they are going to scream like mad if there isn't any. But in the end > they start reading the code anyway, even if there is docu, because they > don't trust anything but their own eyes and brain. ports system == really really large documentation about ports system == really really large (relatively) Anything else? -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: All this and documentation too? (was: cvs commit: src/sys/isa sio.c))
On Sat, Jun 26, 1999 at 03:08:10PM +0200, Nick Hibma wrote: > > And they are going to scream like mad if there isn't any. But in the end > they start reading the code anyway, even if there is docu, because they > don't trust anything but their own eyes and brain. ports system == really really large documentation about ports system == really really large (relatively) Anything else? -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: All this and documentation too? (was: cvs commit: src/sys/isa sio.c))
> On Wed, Jun 23, 1999 at 07:20:56PM -0400, Chuck Robey wrote: > > But one thing I like is, although FreeBSD *does* try to appease user > > demands, it's controlled by programmers, not users, so if something is > > a technically extemely evil idea, no matter how the masses yell for it, > > it will NOT happen. > > Programmers need documentation too. And they are going to scream like mad if there isn't any. But in the end they start reading the code anyway, even if there is docu, because they don't trust anything but their own eyes and brain. It's all documented in C anyway. Nick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: All this and documentation too? (was: cvs commit: src/sys/isa sio.c))
> On Wed, Jun 23, 1999 at 07:20:56PM -0400, Chuck Robey wrote: > > But one thing I like is, although FreeBSD *does* try to appease user > > demands, it's controlled by programmers, not users, so if something is > > a technically extemely evil idea, no matter how the masses yell for it, > > it will NOT happen. > > Programmers need documentation too. And they are going to scream like mad if there isn't any. But in the end they start reading the code anyway, even if there is docu, because they don't trust anything but their own eyes and brain. It's all documented in C anyway. Nick To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: All this and documentation too? (was: cvs commit: src/sys/isa sio.c))
Hi Chuck, On Wed, Jun 23, 1999 at 07:20:56PM -0400, Chuck Robey wrote: > But one thing I like is, although FreeBSD *does* try to appease user > demands, it's controlled by programmers, not users, so if something is > a technically extemely evil idea, no matter how the masses yell for it, > it will NOT happen. Programmers need documentation too. N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: All this and documentation too? (was: cvs commit: src/sys/isa sio.c))
Hi Chuck, On Wed, Jun 23, 1999 at 07:20:56PM -0400, Chuck Robey wrote: > But one thing I like is, although FreeBSD *does* try to appease user > demands, it's controlled by programmers, not users, so if something is > a technically extemely evil idea, no matter how the masses yell for it, > it will NOT happen. Programmers need documentation too. N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in <37514...@cs.colorado.edu> To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: NEWBUS-ifyed ISA-PnP Question.
On Sat, 26 Jun 1999 [EMAIL PROTECTED] wrote: > Hi, > > I believe someone working on NEWBUS-ifying ISA-PnP. > How will they implement it? > I think current framework is like this. >++ ++ > ...|ISA DEV | |ISA-hint|<-This device provides >++ ++what device is connected > | || the ISA bus. > --ISA-- >| >+-+ >|Nexus or ISAB| >+-+ > > > 1. Is the figure true? > 2.If so,where do they attach ISA-PnP mechanism? > attach it like ISA-hint device,modify ISA Bus code or isapnpbus > other than ISA-Bus? > 3.How do I add ISA-PnP device? > 4.How do I add PnP mechanism other than ISA-PnP. This diagram is correct. The ISA-PnP driver is similar to the ISA-hint driver in that it doesn't probe and attach devices itself but creates devices which other drivers can attach to. I have modified the api between the ISA device enumerators (ISA-hint and ISA-PnP) to allow them to specify a set of resource alternatives and a callback function which can select a single alternative. Other PnP mechanisms should fit into this scheme easily. I had ACPI in mind when I was putting this system together. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: NEWBUS-ifyed ISA-PnP Question.
On Sat, 26 Jun 1999 takaw...@shidahara1.planet.sci.kobe-u.ac.jp wrote: > Hi, > > I believe someone working on NEWBUS-ifying ISA-PnP. > How will they implement it? > I think current framework is like this. >++ ++ > ...|ISA DEV | |ISA-hint|<-This device provides >++ ++what device is connected > | || the ISA bus. > --ISA-- >| >+-+ >|Nexus or ISAB| >+-+ > > > 1. Is the figure true? > 2.If so,where do they attach ISA-PnP mechanism? > attach it like ISA-hint device,modify ISA Bus code or isapnpbus > other than ISA-Bus? > 3.How do I add ISA-PnP device? > 4.How do I add PnP mechanism other than ISA-PnP. This diagram is correct. The ISA-PnP driver is similar to the ISA-hint driver in that it doesn't probe and attach devices itself but creates devices which other drivers can attach to. I have modified the api between the ISA device enumerators (ISA-hint and ISA-PnP) to allow them to specify a set of resource alternatives and a callback function which can select a single alternative. Other PnP mechanisms should fit into this scheme easily. I had ACPI in mind when I was putting this system together. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: [Re: [Re: coarse vs fine-grained locking in SMP systems]]
On 26-Jun-99 Jesus Monroy wrote: > The part I'm lost on is "can change things from under it". > From under what? I assume the statement means "it" as being > the code or driver. So the question begs, what things can > change? The assumption that changes is that your code assumes (well mine does :) that it can only have one processor running at at once for routines like open, read, etc.. So no locking is done to protect those routines. Like what happens if CPU 0 is running your drivers open code, then CPU 1 starts running it (because a user program did an open call) then your driver will be confused because it assumes that the open call is only being executed by one CPU. To protect against it you'd need to grab a mutex when you enter open (or block waiting for the other CPU to release it) --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum PGP signature
Re: [Re: [Re: coarse vs fine-grained locking in SMP systems]]
On 26-Jun-99 Jesus Monroy wrote: > The part I'm lost on is "can change things from under it". > From under what? I assume the statement means "it" as being > the code or driver. So the question begs, what things can > change? The assumption that changes is that your code assumes (well mine does :) that it can only have one processor running at at once for routines like open, read, etc.. So no locking is done to protect those routines. Like what happens if CPU 0 is running your drivers open code, then CPU 1 starts running it (because a user program did an open call) then your driver will be confused because it assumes that the open call is only being executed by one CPU. To protect against it you'd need to grab a mutex when you enter open (or block waiting for the other CPU to release it) --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum pgpgT2P6qWtwk.pgp Description: PGP signature
Re: NIS Question Thanks!!
Yes. NIS is braindead. The amount of traffic is not that large. The problem you will see is that it takes longer for a prompt to return due to NIS when the network is heavily loaded and latencies rise. When you log in to a Sun box (most often NIS-ified) for example, you will see that it takes ages. When you switch off NIS in /etc/nsswitch.conf you get quite a speedup on this for most cases. Apart from DNS. You will have to replace libresolv.* for getting that without NIS. :-( Solution: Very simple, make every machine a NIS slave server. Works here like a charm across 6 machines (tiny network, I know). Once in a while a machine pops to an external one, but that can be solved easily enough by killing ypbind and restarting it. I have not looked at either memory or disk usage. Hope this helps. Nick > Does NIS support any kind of caching? Or does it go out to the NIS server > every time someone logs in? Is there a way to set something up? After I > start putting most of the systems on this, I imagine that network usage is > going to raise dramatically... > > Thanks for any info you can provide! > > > > Nick > [EMAIL PROTECTED] > Web Page: http://www.lopresti.dhs.org/users/nick > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > > -- e-Mail: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: NIS Question Thanks!!
Yes. NIS is braindead. The amount of traffic is not that large. The problem you will see is that it takes longer for a prompt to return due to NIS when the network is heavily loaded and latencies rise. When you log in to a Sun box (most often NIS-ified) for example, you will see that it takes ages. When you switch off NIS in /etc/nsswitch.conf you get quite a speedup on this for most cases. Apart from DNS. You will have to replace libresolv.* for getting that without NIS. :-( Solution: Very simple, make every machine a NIS slave server. Works here like a charm across 6 machines (tiny network, I know). Once in a while a machine pops to an external one, but that can be solved easily enough by killing ypbind and restarting it. I have not looked at either memory or disk usage. Hope this helps. Nick > Does NIS support any kind of caching? Or does it go out to the NIS server > every time someone logs in? Is there a way to set something up? After I > start putting most of the systems on this, I imagine that network usage is > going to raise dramatically... > > Thanks for any info you can provide! > > > > Nick > n...@chromatix.com > Web Page: http://www.lopresti.dhs.org/users/nick > > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message > > -- e-Mail: hi...@skylink.it To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: [Re: [Re: coarse vs fine-grained locking in SMP systems]]
"Daniel J. O'Connor" <[EMAIL PROTECTED]> wrote: > On 26-Jun-99 Jesus Monroy wrote: > > > An approach like that can't possibly be sufficient if code has been > > > written with the assumption that only interrupt-like events or > > > blocking calls can change things from under it. There is quite > > > a bit of code in FreeBSD that relies on this. > > > > > Can you elaborate on this a bit more? I think I missing > > some of the finer points on what you are saying. > > > > I work on interrupt driven device drivers and I'm trying > > to see how this ties in. > > > The reason is that if kernel code is written to not protect against > reentrancy then it will have race conditions in SMP. > > The splXXX() macros are used in drivers to protect against code > reentrancy when an interrupt occurs. Usually they are around > routines which modify a data structure which can also be > modified by the drivers interrupt handler. > Still not getting. I'm aware of 'race conditions' and splxxx() macros. I've written and have a working driver under *BSD. So, I guess I need to ask a more specific question. The statement was made that code would not port easily in a now lost part of the discussion. I agree with that. The part I'm lost on is "can change things from under it". From under what? I assume the statement means "it" as being the code or driver. So the question begs, what things can change? *..Certainly Hardware interfaces can't change. *..Buffer, locks and flags should be under it's direct control, so I see no issues there. *..The code itself will not change. *..Timing and commit issue, beyond immediate buffers are beyond the control of the driver. There is a possiblity that link lists would change and alter data flow, but that is expected. So there is either a mental block going on or I must be missing something obvious. Mind you I'm not trying to start an arguement, just trying to figure out what was said and how it relates to my work. Perhaps it does not relate? --- "I'd rather pay for my freedom than live in a bitmapped, pop-up-happy dungeon like NT." http://www.performancecomputing.com/features/9809of1.shtml Get free e-mail and a permanent address at http://www.netaddress.com/?N=1 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [Re: [Re: coarse vs fine-grained locking in SMP systems]]
"Daniel J. O'Connor" wrote: > On 26-Jun-99 Jesus Monroy wrote: > > > An approach like that can't possibly be sufficient if code has been > > > written with the assumption that only interrupt-like events or > > > blocking calls can change things from under it. There is quite > > > a bit of code in FreeBSD that relies on this. > > > > > Can you elaborate on this a bit more? I think I missing > > some of the finer points on what you are saying. > > > > I work on interrupt driven device drivers and I'm trying > > to see how this ties in. > > > The reason is that if kernel code is written to not protect against > reentrancy then it will have race conditions in SMP. > > The splXXX() macros are used in drivers to protect against code > reentrancy when an interrupt occurs. Usually they are around > routines which modify a data structure which can also be > modified by the drivers interrupt handler. > Still not getting. I'm aware of 'race conditions' and splxxx() macros. I've written and have a working driver under *BSD. So, I guess I need to ask a more specific question. The statement was made that code would not port easily in a now lost part of the discussion. I agree with that. The part I'm lost on is "can change things from under it". From under what? I assume the statement means "it" as being the code or driver. So the question begs, what things can change? *..Certainly Hardware interfaces can't change. *..Buffer, locks and flags should be under it's direct control, so I see no issues there. *..The code itself will not change. *..Timing and commit issue, beyond immediate buffers are beyond the control of the driver. There is a possiblity that link lists would change and alter data flow, but that is expected. So there is either a mental block going on or I must be missing something obvious. Mind you I'm not trying to start an arguement, just trying to figure out what was said and how it relates to my work. Perhaps it does not relate? --- "I'd rather pay for my freedom than live in a bitmapped, pop-up-happy dungeon like NT." http://www.performancecomputing.com/features/9809of1.shtml Get free e-mail and a permanent address at http://www.netaddress.com/?N=1 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: [Re: coarse vs fine-grained locking in SMP systems]
On 26-Jun-99 Jesus Monroy wrote: > > An approach like that can't possibly be sufficient if code has been > > written with the assumption that only interrupt-like events or > > blocking calls can change things from under it. There is quite a bit > > of code in FreeBSD that relies on this. > Can you elaborate on this a bit more? I think I missing > some of the finer points on what you are saying. > > I work on interrupt driven device drivers and I'm trying > to see how this ties in. The reason is that if kernel code is written to not protect against reentrancy then it will have race conditions in SMP. The splXXX() macros are used in drivers to protect against code reentrancy when an interrupt occurs. Usually they are around routines which modify a data structure which can also be modified by the drivers interrupt handler. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum PGP signature
Re: [Re: coarse vs fine-grained locking in SMP systems]
On 26-Jun-99 Jesus Monroy wrote: > > An approach like that can't possibly be sufficient if code has been > > written with the assumption that only interrupt-like events or > > blocking calls can change things from under it. There is quite a bit > > of code in FreeBSD that relies on this. > Can you elaborate on this a bit more? I think I missing > some of the finer points on what you are saying. > > I work on interrupt driven device drivers and I'm trying > to see how this ties in. The reason is that if kernel code is written to not protect against reentrancy then it will have race conditions in SMP. The splXXX() macros are used in drivers to protect against code reentrancy when an interrupt occurs. Usually they are around routines which modify a data structure which can also be modified by the drivers interrupt handler. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum pgp7tLYitRnKL.pgp Description: PGP signature
