Re: qsort() documentation

[Erik Trulsson]

Quoting Warren Block :


On Tue, 19 Apr 2016, Aleksander Alekseev wrote:


Why Wikipedia, specifically?  There are a lot of places that describe
quicksort.  How about just

  Note: This implementation of qsort() is designed to avoid the
  worst-case complexity of N**2 that is often seen with standard
  versions.


I would say that this statement is just false. Worst-case complexity is
still N**2. How about something like:

"""
This implementation of qsort() has worst case complexity of N**2.
However measures were taken that make it very unlikely that for some
random input N**2 swaps will be made. It's still possible to generate
such an input on purpose though. See code below for more details.
"""


Okay:

  The quicksort algorithm worst-case is O(N**2), but this implementation
  has been designed to avoid that for most real data.


Keep in mind that there is no requirement whatsoever that the qsort()
function uses the quicksort algorithm, even if that is a common way to  
implement qsort()


Also, worst-case is worst-case, no matter how unlikely.




___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CURRENT: ath0: stuck beacon; resetting (bmiss count 4)

[Erik Trulsson]

Quoting O. Hartmann ohart...@zedat.fu-berlin.de:


Since a couple of days I get this weird console-and-log-spamming message:

ath0: stuck beacon; resetting (bmiss count 4)

The machine in question is running the most recent CURRENT right now:

FreeBSD 11.0-CURRENT #2 r272471: Fri Oct  3 13:03:58 CEST 2014 amd64

and the box acts as a gateway with WiFi access point via hostapd and  
this WiFi hardware:


[...]
ath0: Atheros 9287 mem 0xf7e0-0xf7e0 irq 16 at device 0.0 on pci1
ath0: [HT] enabling HT modes
ath0: [HT] enabling short-GI in 20MHz mode
ath0: [HT] 1 stream STBC receive enabled
ath0: [HT] 1 stream STBC transmit enabled
ath0: [HT] 2 RX streams; 2 TX streams
[...]
ath0: 2GHz radio: 0x; 5GHz radio: 0x00c0

What is this and how can I get rid of it?


It means that you have run into a well-known and long lasting hardware  
bug in Atheros Wifi chipsets, where they sometimes get stuck and stops  
sending out beacons.
You get that message when the device driver detects that this has  
happened and resets the chip to get things going again.


There is, AFAIK, no way of making sure the problem cannot happen, but  
you might be able to reduce the frequency of it happening by reducing  
the amount of interference you receive from other wireless devices.





___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: stable/9 still looking for packages at 9-current

[Erik Trulsson]

On Mon, Jan 09, 2012 at 01:16:59PM -0500, Arnaud Lacombe wrote:
 Hi,
 
 On Mon, Jan 9, 2012 at 9:37 AM, Mark Linimon lini...@lonesome.com wrote:
  On 9. Jan 2012, at 01:04 , Arnaud Lacombe wrote:
  So you are saying that FreeBSD is currently providing on
  ftp://ftp.freebsd.org/pub images tagged as being 9.0 RELEASE (with
  checksum provided), in a `releases' directory, which are not actually
  release images per-se ?
 
  Excellent!  You've shown the ability to understand flat, declarative,
  sentences that have no qualifying phrases.
 
 FWIW, this was more a sarcastic sentence pointing out that FreeBSD is
 currently officially distributing non-released build in a directory
 which might leads users to consider this is the official release, thus
 misleading them.

That build is intended to become the official release unless some
last-minute showstopper problem is found. (Unlikely, but has happened before.)

The build is being distributed in advance of the official announcement
to make sure it is available on all mirrors at the moment the
announcement is made.



-- 
Insert your favourite quote here.
Erik Trulsson
ertr1...@student.uu.se
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: HEADS UP: ports/ and 10.0-CURRENT

[Erik Trulsson]

On Tue, Sep 27, 2011 at 08:22:54AM -0400, Robert Huff wrote:
 
 krad writes:
   we can leave that to our grand children to figure out though 8)
 
   Wasn't that what people said about two-digit years?

Not quite.  There they mostly said No way that this program will still
be in use when two-digit years becomes a problem!  




-- 
Insert your favourite quote here.
Erik Trulsson
ertr1...@student.uu.se
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Getting /usr/src/ from SVN directly?

[Erik Trulsson]

On Sat, Mar 26, 2011 at 10:31:39AM -0700, Nerius Landys wrote:
  one could also use the -F switch in connection with mergemaster(8).
 
 From mergemaster manpage:
 
 If the files differ only by VCS Id ($FreeBSD) install the new file.
 
 Yes that is exactly what I want, thanks.
 
 By the way, are there any other ways that are more preferred to get
 /usr/src/ than doing what I've done, which is using
 devel/subversion-freebsd to checkout head into /usr/src/?

No, that is probably the best way.

An older method (which still works) is to use csup/cvsup to download a
local copy of the whole CVS repository and then use cvs to checkout
/usr/src from this copy.
Before the switch to subversion this was the preferred way.




-- 
Insert your favourite quote here.
Erik Trulsson
ertr1...@student.uu.se
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Request for testing/comments -- import of new dialog/libdialog

[Erik Trulsson]

On Wed, Jan 05, 2011 at 06:57:14PM -0600, Nathan Whitehorn wrote:
 As part of work on a new installer, I would like to update the base 
 system dialog and libdialog to the newer one provided by Thomas Dickey 
 (http://invisible-island.net/dialog/, ports as devel/cdialog). This is a 
 much nicer, fuller featured version of dialog that simplifies the 
 creation of new dialog-using tools (a longstanding impediment to a new 
 versions of sade, sysinstall, etc.), and is under a marginally better 
 license (LGPL2 instead of GPL2).
 
 Patches to effect the import can be found at:
 - http://people.freebsd.org/~nwhitehorn/libdialog-update.diff
 
 What the patches do:
 - Replaces dialog(1) with a new version. All command-line options of the 
 old dialog except --fstree are accepted by the new dialog, and the ports 
 options framework continues to work without modification.
 - Renames libdialog to libodialog (old dialog). The new dialog library 
 has a much more pleasant API than the old one -- which directly implies 
 that it has a substantially different API. Until sysinstall, sade, and 
 tzsetup are replaced or rewritten, we need to keep the old library around.
 - Modifies sysinstall, sade, and tzsetup to link to libodialog instead 
 of libdialog.
 - Deletes all man pages and examples associated with libodialog. This is 
 deprecated code.
 - Installs new dialog library as libdialog
 - Bumps __FreeBSD_version to 900030

Are there any ports which link to the old version of libdialog, and if
so, what will happen to them?

Why not keep the old version as libdialog and instead use a new name
for the new library (libndialog or whatever) ?
(I am not saying you should do this - it is a real question.)



-- 
Insert your favourite quote here.
Erik Trulsson
ertr1...@student.uu.se
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Clang now builds world and kernel, on i386 and amd64

[Erik Trulsson]

On Sun, Sep 26, 2010 at 02:21:51PM +0200, Bartosz Stec wrote:
   W dniu 2010-09-24 16:34, Dimitry Andric pisze:
  On 2010-09-24 14:13, Bartosz Stec wrote:
  Could you please try to rename this make.conf to e.g. 
  make.conf.disable,
  and retry the world build?
  Still the same without make.conf. My personal guess is, that clang
  builded by clang with CPUTYPE=athlon-xp is somehow broken. I don't think
  CFLAGS=-O2 -pipe could do any harm, and also note that clang builded by
  GCC with exactly the same make.conf has no problems with world 
  building :)
 
  I still cannot reproduce your issue...  To check, I have built world
  with CPUTYPE=athlon-xp, verified it used -O2 -pipe -march=athlon-xp as
  compilation flags for the world stage, and installed the resulting clang
  executables.
 
  Those clang executables do not exhibit the same problem as yours do;
  they can build tblgen (during the bootstrap-tools stage) fine.
 
  I suggest you comment out the CPUTYPE macro in make.conf for now,
  rebuild your world with gcc, and then rebuild it with clang again, to
  see if the issue goes away.
 
 Indeed, I was right. Problem is gone after hashing out CPUTYPE line, 
 building world with GCC, and with clang after that. Now world is 
 building without problems.
 
 But hey, i just realized that:
 
 # dmesg | grep -i cpu
 CPU: mobile AMD Athlon(tm) XP 2200+ (1800.11-MHz 686-class CPU)
 
 I simply forgot that about a year ago I changed Athlon XP in this BOX to 
 Athlon MP and I didn't changed CPUTYPE in make.conf...
 So maybe clang in fact did exactly what it should and created binary 
 designed to other CPUTYPE ;) I don't know exact differences between 
 Athlon XP/MP architecture (registers specially) but I just started 
 another try with CPUTYPE=Athlon-mp and I will post results :)

The only difference between Athlon XP and Athlon MP is that the MP
variants are certified for multi-processor use (in reality most Athlon
XP also worked just fine in multi-processor systems, or could easily be
modified to do so.)  Available instructions and registers are identical
between the two.  Mobile variants of the Athlon XP should also be
identical from a programming point of view.



-- 
Insert your favourite quote here.
Erik Trulsson
ertr1...@student.uu.se
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Results of BIND RFC

[Erik Trulsson]

On Fri, Apr 02, 2010 at 03:14:54AM -0700, Jeremy Chadwick wrote:
 
 [1]: FreeBSD really needs to move away from the base system as a
 concept, as I've ranted about in the past.  Or if it cannot, the base
 system needs to start using pkg_* (somehow)

No, it does not need to do that.  It might be a good idea (but I am far
from convinced of it), but there most certainly is no *need* to move in
that direction.




-- 
Insert your favourite quote here.
Erik Trulsson
ertr1...@student.uu.se
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: HEADS UP: /bin and /sbin are now dynamically linked

[Erik Trulsson]

On Mon, Nov 17, 2003 at 09:00:20AM -0500, Michael Edenfield wrote:
 * Erik Trulsson [EMAIL PROTECTED] [031116 23:21]:
  On Sun, Nov 16, 2003 at 07:24:00PM -0700, Brent Jones wrote:
   This is just a case of OS evolution.  /sbin used to be the place where 
   the statically linked recovery things would be placed, in case the 
   shared libraries got hosed.  The only things that needed to be 
   statically linked though, were system utilities, which is why people 
   probably started to associate the s with system, rather than static.
   
   When this happened, you started to see the duplicates that used to 
   exist in /bin (or /usr/bin) and /sbin disappear.  Since you still need 
   a place to have statically linked recovery utilities, /rescue was 
   created.  Now you see the duplicates in /bin (or /usr/bin) and /rescue 
   instead.
  
  Do you have any references for this?  Every single place that I can
  find explains /sbin as system binaries.  I have also never heard of
  there ever being duplicates in /bin of the files in /sbin.
 
 Also, wouldn't the names 'bin' and 'sbin' pre-date the existiance of
 dynamically linked binaries?

Yeah, that is what I thought too, but it does not seem to to be the
case.
As far as I can tell (after using Google for quite a bit) shared
libraries were first introduced in Unix with SysVR3, with the model
currently in use first appearing in SunOS 4 (I have no idea what they
looked like in SysVR3.)  /sbin seems to have first appeared in SysVR4,
which postdates both of the above.
/sbin seems to have been introduced to BSD sometime between 4.3BSD and
4.4BSD.
(And SysVR4-derived systems seem to have /bin just as a symlink to
/usr/bin, with /sbin containing only what is needed to boot the system
far enough to mount /usr, with system binaries otherwise appearing in
/usr/sbin and normal user binaries in /usr/bin.  Solaris does
appear to have dynamically linked duplicates in /usr/sbin of the
statically linked programs appearing in /sbin.)

  AFAIK the primary difference between the
 two was the /bin was typically in a user's PATH and /sbin was not.

This is apparently one of things that differ between SysV- and BSD-
derived systems.


-- 
Insert your favourite quote here.
Erik Trulsson
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: 4 Clause license?

[Erik Trulsson]

On Mon, Nov 17, 2003 at 02:48:08PM -0500, Rod Taylor wrote:
 The PostgreSQL group has recently had a patch submitted with a snippet
 of code from FreeBSDs src/bin/mkdir/mkdir.c.
 
 http://www.freebsd.org/cgi/cvsweb.cgi/src/bin/mkdir/mkdir.c?annotate=1.27
 
 Is this intentionally under the 4 clause license or does the copyright
 from the website (2 clause) applied to everything that is non-contrib?
 
 http://www.freebsd.org/copyright/freebsd-license.html

That copyright notice on the website should apply to everything that is
not under some other license.  Different parts of the system is under
different licenses and copyrights depending on who wrote it.
The mkdir.c *was* under the 4 clause license. However all material that
was part of the original BSDs and thus was copyrighted by The Regents
of the University of California has had its license changed such that
clause 3 (the advertising clause) no longer apply.  This would seem to
include mkdir.c
Most of the files in the source tree have not had their copyright
notices updated to reflect this.
See http://www.freebsd.org/copyright/license.html  for details on this
license.


-- 
Insert your favourite quote here.
Erik Trulsson
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: HEADS UP: /bin and /sbin are now dynamically linked

[Erik Trulsson]

On Sun, Nov 16, 2003 at 07:24:00PM -0700, Brent Jones wrote:
 
 On Nov 16, 2003, at 9:22 AM, Richard Coleman wrote:
 Robert M.Zigweid wrote:
 I'll admit to being mostly a lurker here, but isn't the point of 
 /sbin to be statically linked.  That's what the 's' stands for?
 Second question.  This seems to imply that /sbin and /bin both have 
 to have the same behavior?  I have no problem with /bin being 
 dynamically linked, but what if I want /bin to be dynamic and /sbin 
 static?
 Regards,
 Robert M. Zigweid
 
 I'm not sure what that would accomplish.  If a system was broken such 
 that the dynamically linked binaries in /bin didn't work, the 
 utilities in /sbin wouldn't be enough to fix the system.  For 
 instance, you wouldn't have a shell or ls.
 
 This is just a case of OS evolution.  /sbin used to be the place where 
 the statically linked recovery things would be placed, in case the 
 shared libraries got hosed.  The only things that needed to be 
 statically linked though, were system utilities, which is why people 
 probably started to associate the s with system, rather than static.
 
 When this happened, you started to see the duplicates that used to 
 exist in /bin (or /usr/bin) and /sbin disappear.  Since you still need 
 a place to have statically linked recovery utilities, /rescue was 
 created.  Now you see the duplicates in /bin (or /usr/bin) and /rescue 
 instead.

Do you have any references for this?  Every single place that I can
find explains /sbin as system binaries.  I have also never heard of
there ever being duplicates in /bin of the files in /sbin.



-- 
Insert your favourite quote here.
Erik Trulsson
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Anyone object to the following change in libc?

[Erik Trulsson]

On Fri, Oct 31, 2003 at 10:06:43AM -0500, Garrett Wollman wrote:
 On Fri, 31 Oct 2003 18:01:34 +1100 (EST), Bruce Evans [EMAIL PROTECTED] said:
 
  POSIX requires in addition [u]int{8,16,32}_t, and [u]int64_t if 64 bit
  integer types exist.  It says that the existence of int8_t implies
  that a byte is 8 bits and CHAR_BIT is 8.  I'm not sure what prevents
  int8_t being smaller than char.
 
 Nothing can be smaller than char (except bitfields, which you can't
 take the size of anyway).

Perhaps not smaller in terms of the sizeof operator, but why can't one
have a 16-bit char, and an int8_t which occupies 16 bits, but only uses
8 of them - the other 8 being padding?

 
 The full story:
 
 The POSIX sockets standard (I forget which letter it had) introduced
 uint8_t et al, but was aligned to C90.  That amendment was integrated
 into the main text at the same time as C99 was, and late in the
 process we realized that C99's definition of uint8_t is much stricter
 than what the socket standard expected.  (Specifically, the socket
 standard allows uint8_t to have padding bits that do not participate
 in the domain of the type, but C99 does not.)  Faced with the choice

Where in C99 does it say that uint8_t can't have padding bits?
I can't find anything in n869.txt to that effect.
As far as I can tell, the only type that is not allowed to have any
padding bits or trap representations is unsigned char.


 of having to invent from whole cloth a completely new set of
 interfaces to describe packing and unpacking eight-bit network data in
 nine- or sixteen-bit characters, or specifying an explicit byte size,
 we chose the latter.  It helped that there were no more 36-bit
 platforms to be concerned about.  (Some would say that this was a
 rather belated recognition of a choice the industry made two decades
 ago  There was, however, a 36-bit implementation of FIPS 151-2, by
 UNISYS.)


-- 
Insert your favourite quote here.
Erik Trulsson
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Anyone object to the following change in libc?

[Erik Trulsson]

On Fri, Oct 31, 2003 at 06:20:17PM +0100, Stefan Farfeleder wrote:
 On Fri, Oct 31, 2003 at 04:43:37PM +0100, Erik Trulsson wrote:
 
  Perhaps not smaller in terms of the sizeof operator, but why can't one
  have a 16-bit char, and an int8_t which occupies 16 bits, but only uses
  8 of them - the other 8 being padding?
 
 7.18.1.1 Exact-width integer types
 
 1 The typedef name intN_t designates a signed integer type with width N, no padding
   bits, and a two's complement representation. Thus, int8_t denotes a signed integer
   type with a width of exactly 8 bits.

I see.  My confusion stems from the fact that n869.txt (the last
publically available draft of the C99 standard) says

   7.18.1.1  Exact-width integer types

   [#1] The typedef name intN_t  designates  a  signed  integer
   type  with  width  N.  Thus, int8_t denotes a signed integer
   type with a width of exactly 8 bits.

The , no padding bits part is apparently one of the things that were changed
between n869.txt and the final standard.

Note to self: I really need to get a copy of the final C99 standard as
soon as I can afford one.

 
  Where in C99 does it say that uint8_t can't have padding bits?
  I can't find anything in n869.txt to that effect.
  As far as I can tell, the only type that is not allowed to have any
  padding bits or trap representations is unsigned char.
 
 uint8_t is int8_t's corresponding unsigned type.  This means
 sizeof(uint8_t) == sizeof(int8_t), thus uint8_t can't have padding bits
 either.

Yes, with the quote from the standard you supplied above, that becomes
clear.


-- 
Insert your favourite quote here.
Erik Trulsson
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: ethercons: ethernet console driver for 5-current

[Erik Trulsson]

On Wed, Oct 22, 2003 at 12:30:41AM -0700, Terry Lambert wrote:
 Peter Jeremy wrote:
  As with the Linux driver, communication happens at the ethernet link
  layer, using protocol number 0x0666 (entertaining choice).
  
  If Linux is using 0x0666, we should probably pick a different number
  since we're not wire compatible.  Though coming up with a common
  protocol would be even better.
 
 0x666 hex is 1638 decimal, and it's taken:
 
 cnip1638/tcp  CableNet Info Protocol
 cnip1638/udp  CableNet Info Protocol

That would be relevant if this protocol used TCP or UDP.
My understanding is that it doesn't, in which case those port
assignments are quite irrelevant.

Looking at the protocol types listed in /usr/include/net/ethernet.h
seems more relevant, unless I have misunderstood something.

 
 Basically, this is just an experimental protocol that's being played
 with here, and if it ever becomes real, then it will need an IANA
 protocol number assignment before it's widely deployed.

Are you sure that IANA would be the right organisation, since AIUI this
isn't a protocol running on top of IP ?

 
 -- Terry

-- 
Insert your favourite quote here.
Erik Trulsson
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: hiding e-mail adresses needed badly

[Erik Trulsson]

On Thu, Oct 16, 2003 at 04:43:27AM -0500, Peter Schultz wrote:
 At this point in time it's downright irresponsible not to hide our 
 addresses.
 
 I've been lurking on this list about a month to get caught up with 
 -current issues.  Friday was both the first mail I sent to the list,
 and the first use of this e-mail address.  The only incoming mail was 
 from the FreeBSD lists I subscribed to.  However, since that fateful 
 e-mail I have been viciously attacked by spammers posing as Microsoft 
 security updaters.  These spams include attachments making them all 
 around 150KB in size.  Maybe others of you have seen them?

I guess you are referring to the W32.Swen worm?  I guess most people
have seen that one by now.

 
 As far as I can tell, these guys are targeting the FreeBSD lists, 
 exploiting them terribly!  This list's charter states that spam will be 
 blocked.  Please enforce the list charter, with prejudice.

The FreeBSD lists are not targeted specially.
That worm mainly harvests e-mail addresses from newsgroups (and from
files stored on infected computers.)
There are several mail-news gateways for this list (and other freebsd
lists), so this is probably where it got your mail-address.
Since these gateways are not under the control of FreeBSD.org there
isn't much that can be done about it.
These spams are mainly not sent through the lists so they can't be
blocked there (even though lots and lots of spam is blocked by the
FreeBSD list servers.)

 
 It would be best if subscribers could just choose to have their address 
 published or not.  I can understand being so dedicated to the cause that 
 you're willing to take on some spam.  Non-subscribers addresses should 
 definitely not be published.
 
 Sincerely,
 Pete...
 
 Wilko Bulte wrote:
 On Wed, Oct 15, 2003 at 03:29:21PM +0400, Andrey Chernov wrote:
 
 
 I fail to see why this is relevant to -current but OK.. I think that
 the opportunity to do this has long since passed. Just type your name
 in Google and see what happens..
 
 Wilko
 
 
 Due to increased activity of SPAM harvesters what are our plans to hide 
 our addresses from public WWW? I mean all browseable mailing lists, 
 FreeBSD site, CVS via WWW, PRs, ports and docs.

Note that there are many web-archives of the mailing lists. Lots of
them are run by other people.  You need to talk to them too.

 
 As I think, simple user [at] domain.com form will be enough to stop 
 them.
 

-- 
Insert your favourite quote here.
Erik Trulsson
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Supfile tag for 5.2 rc

[Erik Trulsson]

On Thu, Oct 16, 2003 at 09:12:12AM +1100, Nigel Weeks wrote:
 Can someone give me the supfile tag for the latest 5.2 release candidate?

No.  There is no 5.2 release candidate, so getting it might be a bit
difficult.
The closest you can get at the moment is to get the latest -CURRENT,
with the tag for that being '.' as usual.

 
 I'm not sure if 'RELENG_5_2' will work...

I am sure it will not work, since that tag does not yet exist, and will
not exist until 5.2-RELEASE is almost ready to go.


-- 
Insert your favourite quote here.
Erik Trulsson
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Release Engineering Status Report

[Erik Trulsson]

On Tue, Sep 16, 2003 at 10:30:50AM -0600, Scott Long wrote:
 Mike Silbersack wrote:
 On Tue, 16 Sep 2003, Scott Long wrote:
 
 
 Patches have been floated on the mailing list that revert PAE in its
 various stages.  Maybe those need to be brought back up.  Silby?  Tor?
 
 Scott
 
 
 I believe that Tor's commit on August 30th resolved the PAE-related
 problems, so there is no need for a reversion.  Since that time, I've seen
 three panics posted:
 
 1.  Some netinet/ related panic which I couldn't make heads or tails of,
 and I haven't any followup reports from the poster.
 
 2.  Maxim's buildworld -j64 memory kmap entry exhaustion panic, which can
 be fixed by increasing the number of kmap entries.  (Tor has a patch for
 this, I will probably commit it soon.)
 
 3.  A panic caused by sending 64K-1 ping packets, which I can't reproduce.
 
 (There's also a small problem with if_xl on pentium-1 machines, but since
 it's my fault and I'm waiting on test results from a guy, we won't talk
 about it.)
 
 (Hey, anyone have a pentium-200 and a 3com 905B card?  Contact me, further
 testing can't hurt.)
 
 So, as far as I can tell, there are no remaining problems related to PAE;
 I believe that most people are venting frustration that built up between
 August 9th and 30th.
 
 Mike Silby Silbersack
 
 
 Ok, thanks for the update.  Since it is 17 days after Aug 30 and people
 are still upset, the status was very unclear to the Release Engineering
 Team.  So I guess we ened to solicit updates from the people who were
 directly experiencing problems, and ask for everyone else to test it as
 much as possible.

I was one the people who were experiencing stability problems after the
PAE commit.  I had several unexpected panics and could provoke panics
nearly at will on systems that had previously been rock-stable.
After the Aug 30 commit I have not had any panics at all and I have not
experienced any other stability problems either since then.

In my personal experience RELENG_4 is currently quite stable (not
counting any commits made during the last 48 hours or so since I have
not yet tested any of those), but it is of course possible that other
people have run into bugs in components of the kernel that I don't use.


(Note: I do not have PAE enabled in the kernel.  I have no idea what
the situation is for those who actually have enabled PAE, but any
problems that may exist there is non-critical IMO since they would not
affect any pre-existing configurations.)


-- 
Insert your favourite quote here.
Erik Trulsson
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: cvsup sites are all at capacity?

[Erik Trulsson]

On Tue, Sep 16, 2003 at 04:01:39PM -0600, Andrew Lankford wrote:
 I've tried various cvsup sites (normally cvsup2 or cvsup16  )
  and each site returns this message:
 
 Rejected by server: Access limit exceeded; try again later
 
 I've gotten that before but never with all of the hosts out there. 
 Is everyone and their brother doing a make world today,

Probably.  There was a security advisory for OpenSSH released earlier
today, so I would guess just about everybody is trying to update their
systems.

  are the sites down for maintenance, or is something sinister
  going on?
 
 Just wonderin'
 
 Andrew Lankford
  


-- 
Insert your favourite quote here.
Erik Trulsson
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: GCC 3.3.1, new warnings with limits

[Erik Trulsson]

On Sun, Jul 13, 2003 at 01:37:32PM -0500, David Leimbach wrote:
 
 On Sunday, July 13, 2003, at 1:23PM, M. Warner Losh wrote:
 
 :  134 #define __glibcpp_signed(T) ((T)(-1)  0)
 : #define __glibcpp_signed(T) (!((T)(-1)  0))
 
 Why not the simpler:
 
 #define __glibcpp_signed(T) ((T)(-1) = 0)
 
 that way we have an overlap on the range of the two types, so we won't
 get a warning.  We know for a fact that -1 != 0 for all known machine
 types (all machines are two's complement, or are required to behave as
 if they are two's complement, per the standard).
 
 
 You keep saying this... where is this must behave as two's compliment 
 stated?
 
 
 (unsigned int) -1 == 0x(assuming 32-bit int).
 
 or with a valid one's compliment C99 compliant system
 (unsigned int) -1 = 0xfffe;
Only if UINT_MAX happens to be0xfffe, which it probablky won't be.
For all  C99 compliant systems  you have that:
(unsigned int) -1 == UINT_MAX

 
 
 even on a one's complement's machine, without the standard conversion,
 the 'type punning' conversion of -1 would yield 0xfffe, which is
 still  0.
 
 Correct :).  I still don't think C enforces two's compliment.

C doesn't require two's compliment, but  it encourages it.

If you take a signed value and convert it to the corresponding
unsigned type , the result must be equal modulo 2^N to the original
value (where N is the number of bits in the unsigned type. (Ignoring
any padding bits.)) (Actually it is modulo a value one greater than the
largest value representable by the unsigned  type, but this amounts to
the same thing.)
This means that -1 converted to an unsigned type will always be the
largest number representable by that unsigned type.
This is true regardless of how negative numbers are represented.
For two's complement there is no need to change the representation when
converting signed to unsigned values, while this can be needed when
using sign-magnitude or one's-complement.

And to answer the original question:
It is valid to assume that -1 converted to an unsigned integer type
will never be equal to 0.


-- 
Insert your favourite quote here.
Erik Trulsson
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: GCC 3.3.1, new warnings with limits

[Erik Trulsson]

On Sun, Jul 13, 2003 at 02:28:38PM -0500, David Leimbach wrote:
 
 C doesn't require two's compliment, but  it encourages it.
 
 If you take a signed value and convert it to the corresponding
 unsigned type , the result must be equal modulo 2^N to the original
 value (where N is the number of bits in the unsigned type. (Ignoring
 any padding bits.)) (Actually it is modulo a value one greater than the
 largest value representable by the unsigned  type, but this amounts to
 the same thing.)
 This means that -1 converted to an unsigned type will always be the
 largest number representable by that unsigned type.
 This is true regardless of how negative numbers are represented.
 For two's complement there is no need to change the representation when
 converting signed to unsigned values, while this can be needed when
 using sign-magnitude or one's-complement.
 
 
 So for the one way conversion of signed to unsigned it will behave like 
 2's compliment

Signed to unsigned will always give the same result, regardless of how
negative numbers are represented, yes. (And for two's complement this
is the same as the natural way of doing it, while for other
representations some extra work might be needed.)

 all the time. What about back to signed?  I assume that it defaults 
 back to the

If you have try to convert a value to a signed type and the type in
question cannot that value, then the result is implementation-defined.
Implementation-defined means the implementation is free to do whatever
it wants, but it must document what it will do.
Typically implementations won't do anything special but will just keep
the same representation, but this is not something that portable
programs can depend on.

So, on a one's complement machine one would probably have that:
(int)UINT_MAX == 0
(Since UINT_MAX would have the same representation as a negative  zero
on such a machine.)
On a sign-magnitude machine it would probably be
(int)UINT_MAX == INT_MIN
and on a two's complement machine one would probably have
(int)UINT_MAX == -1
but an implementation is also free to trap on integer overflow, just as
it usually does with division by zero. (Or it might do something else.)

Unsigned arithmetic is well-defined in C. Signed arithmetic less so.

 platform's implementation of the signed type which due to the 
 conversion to
 unsigned would also, logically, be encouraged to behave as a 2's 
 compliment signed
 number.  Cute way to make the standard seem flexible.  The overhead 
 of type
 conversion is often overlooked in coding it seems... On some platforms 
 like the
 PPC going from int to float takes a lot longer than one might think... 

That depends on how long one thinks it should take, doesn't it? :-)

 but that
 is another story :).  [no need to answer this... unless we take it out 
 of this thread]
 
 
 And to answer the original question:
 It is valid to assume that -1 converted to an unsigned integer type
 will never be equal to 0.
 
 
 No arguments here. :)  Sorry if we wandered off too far.  It was at 
 least enlightening
 for me and hopefully others.

-- 
Insert your favourite quote here.
Erik Trulsson
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: GCC 3.3.1, new warnings with limits

[Erik Trulsson]

On Sun, Jul 13, 2003 at 01:48:38PM -0600, M. Warner Losh wrote:
 In message: [EMAIL PROTECTED]
 David Leimbach [EMAIL PROTECTED] writes:
 : So for the one way conversion of signed to unsigned it will behave like 
 : 2's compliment
 : all the time. What about back to signed?
 
 Same way.
 
 It will be reduced by the maximum value of the range plus one to do
 the conversion.

No, this case is implementation-defined if the value cannot be
represented by the signed type it is converted to.
(If it can be represented then the value will be preserved.)

 
 See section for 6.3.1.3 for the details.

Yes, please do.

 
 That's why I said 'as if' in my other mail.

-- 
Insert your favourite quote here.
Erik Trulsson
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Compiling with high optimization?

[Erik Trulsson]

On Sun, Feb 09, 2003 at 08:03:57AM -0600, Jacques A. Vidrine wrote:
 On Sat, Feb 08, 2003 at 05:23:01PM -0800, Terry Lambert wrote:
  The compiler
  didn't complain when he checked it before committing it because
  optimization was off by default; it should have complained, e.g.:
   
 Is that really what you meant?  I don't believe it has anything to
 do with optimization; rather, it is to do with lack of `warning'
 flags.  For example, if you build libc with WARNS=5 (so as to get the
 `-Wuninitialized' flag), then you get this warning.
 
  x.c:9:warning: `foo' might be used uninitialized in this function

Some warnings are not generated unless you compile with optimization
on.  The reason for this is that to generate some of the warnings (for
example about uninitialized variables) you need to do some dataflow
analysis and gcc only does this when optimizing.

Take for example this little program:

#include stdio.h
int main(void)
{
int a;
printf(%d\n,a);
return 0;
}

When compiled using 'gcc -O0 -Wall' no warnings are generated. When
compiled with 'gcc -O1 -Wall' you get a warning that 'a' might be used
uninitalized.  (This is the case for gcc 2.95.x at least. I believe the
situation is the same with gcc 3.x)




-- 
Insert your favourite quote here.
Erik Trulsson
[EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Final fix for correlation problem (was Re: rand() is broken)

[Erik Trulsson]

On Mon, Feb 03, 2003 at 07:01:50AM -0500, Thomas David Rivers wrote:
 I'm afraid I don't understand the fix... and how it
 seems to affect the historical behaviour of srand()/rand().
 
 How does it address the understanding that if I use
 srand(28), I will get exactly the same sequence of
 numbers srand(28) produced yesterday, last week, 
 last year?

That understanding is mistaken.

 
 I have worked with programs that depend on exactly
 that behavior.

Then those programs have a bug.
If you need every execution of the program to use the exact same
sequence of pseudo-random numbers then the program need to implement
its own RNG.


 
 That is,  given the same input seed - I expect
 to see the same random sequence again.  

You will - if you generate both sequences during the same program
execution.
There are no guarantees (and has never been) that srand()/rand() will
give the same sequence after an OS update or on a different system or
even between two different runs of the same program.


 
 This requirement would seem to indicate that changing
 srand()/rand() isn't really possible...  And, also,
 I believe, why random() was introduced...

a) srand()/rand() does use different algorithms on different systems so
   depending on some particular algorithm is inherently unportable.
b) random() was not introduced because the sequence from rand()
   couldn't be changed.  It was rather because the calling interface
   for srand()/rand() puts constraints on the implementation that result
   in rand() by necessity being a rather poor RNG.  random() was
   introduced so one could have a RNG with better statistical properties.
c) I believe the algorithm used by rand() *was* changed in -CURRENT
   about two years ago.  (And pretty the same discussion ensued back
   then.)  This change was done because the old algorithm used was
   particularly poor and it was possible to do better.  Now some defect
   in the new algorithm has apparently been discovered which is why it
   needs to be modified again.


 
 Please, oh please, don't change that behavior in 
 srand()/rand().
 
   - Dave Rivers -



-- 
Insert your favourite quote here.
Erik Trulsson
[EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: rand() is broken

[Erik Trulsson]

On Sun, Feb 02, 2003 at 12:06:56PM -0800, Bakul Shah wrote:
  Maybe I missed something, but why cannot you just rip random() from libc, 
  rename it to bakul_shah_random() and use that in your testing code?  Then you
  are safe from any changes to random(), and indeed have a portable RNG if your
  host OS changes.
 
 Yes, *I* can do it but I don't work at every place they do
 simulation!  If in the extreme you are suggesting that a
 portable application shouldn't rely on any OS features, you
 are of course right but that kind of makes mockery of any
 claims of compatibility.  The point of compatibility is to
 not break interfaces unless there is a significant benefit.

If your program depends on the exact algorithm used by random() (or
rand() for that matter) to not change between OS updates (not to
mention between different systems) then that is a bug in your program.

The interface will not change just because a different algorithm is
used.  
The exact sequence of random numbers produced is not a part of the
interface but rather an implementation detail that portable programs
should not depend on.

It might also be worth noting that if a good PRNG is needed then one
should not use random() or rand() since on some systems their output is
not very random.


-- 
Insert your favourite quote here.
Erik Trulsson
[EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Request for info from SiS chipset owners

[Erik Trulsson]

On Sat, Feb 01, 2003 at 12:02:05PM +0100, Soeren Schmidt wrote:
 
 I'm currently in the midst of an ATA chipset support mega rewrite/update,
 and the last item on the list is SiS support.
 
 That where _you_ come into the picture, I need a pciconf -l from your
 SiS based system!
 
 Just reply to this message with the output from pciconf -l and you
 have helped me sort out the myriads of SiS chipsets out there.
 
 -Søren

chip0@pci0:0:0: class=0x06 card=0x chip=0x55961039 rev=0x00 hdr=0x00
isab0@pci0:1:0: class=0x060100 card=0x chip=0x00081039 rev=0x01 hdr=0x00
atapci0@pci0:1:1:   class=0x01018a card=0x chip=0x55131039 rev=0x09 
hdr=0x00
atapci1@pci0:11:0:  class=0x018085 card=0x4d68105a chip=0x4d68105a rev=0x02 
hdr=0x00
none0@pci0:13:0:class=0x03 card=0x63261569 chip=0x63261039 rev=0x0b 
hdr=0x00
ed0@pci0:15:0:  class=0x02 card=0x802910ec chip=0x802910ec rev=0x00 hdr=0x00
none1@pci0:20:0:class=0x03 card=0x chip=0x02051039 rev=0x11 
hdr=0x00

The chipset used on this motherboard is a SiS 5596/5513.
(Even though dmesg likes to claim that the ATA controller is a SiS 5591, 
which it isn't.  It is a SiS 5513.)

-- 
Insert your favourite quote here.
Erik Trulsson
[EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: malloc.conf (was Re: Performance problems with 5.0-RELEASE)

[Erik Trulsson]

On Thu, Jan 23, 2003 at 02:14:46PM -0500, Rahul Siddharthan wrote:
 Dan Nelson wrote:
   # ls -l /etc/malloc.conf 
   lrwxr-xr-x  1 root  wheel  4 Jan 23 11:52 /etc/malloc.conf - HR
  
  H and  should only make a difference if you are low on memory. 
 
 Yes.
 
  R is on
  by default in 5.0 anyway, due to A and J being on by default. 
 
 That's not what the malloc(3) man page suggests -- R seems to have
 nothing to do with A or J.   Perhaps, however, the improvement I see
 is due to turning off A and J (implicitly, ie by not specifying them)?

Read again.  J automatically sets R.
Yes, not having J set should improve performance noticeably compared
with having J set.


-- 
Insert your favourite quote here.
Erik Trulsson
[EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: 80386 out of GENERIC

[Erik Trulsson]

On Sun, Dec 15, 2002 at 12:18:21AM -0500, Craig Reyenga wrote:
 Sorry for butting in, but my $.02 is that 386's are old enough that
 FreeBSD, or any other OS for that matter, shouldn't wait up for them.

Why not?  An OS in itself should not require a lot of CPU power.

 They've gotten to the point where they are basically useless except
 for running older software, which was likely written for them anyways.

They are not useless, and if new software has problems running on them
it is mostly because a lot of new software is big and bloated without
any good reason except for lazy/incompetent programmers.

 If I had a 386 that I wanted FreeBSD on, I'd crack open the old FreeBSD 3.5
 install CD's, assuming it even had a cdrom drive.
 
 I understand why people care about supporting older hardware. Reasons
 such as cost, and the ability to allow code bloat to _really_ manifest
 itself
 come to mind. However, a 386 is just too old for words and should
 be running older software with less features.

Less features and more security problems.  Considering that security
fixes normally don't get applied to the 3.x branch any longer one might
want to be a bit careful running that on a computer connected to the
Net.  Eventually I assume that 4. will be similarily abandoned which
means that you will have to run 5.x to have a secure system.

Personally I strongly disagree with the notion that hardware that is a
mere 10 years old (like some '386s) should be considered too old for
words.  

The only remotely good reason I have heard for removing support for 386
in the default configuration is that having it in would pessimize
performance too much for more modern CPUs.  How valid that reason is I
cannot judge, but I guess it is possible.


(And just FYI, my 386 box is happily running 4.7-stable at the moment
without any problems and I will probably consider updating it to 5.x
when security fixes are no longer automatically applied to 4.x.)

 
 -Craig
 
 - Original Message -
 From: Terry Lambert [EMAIL PROTECTED]
 To: M. Warner Losh [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
 [EMAIL PROTECTED]
 Sent: Saturday, December 14, 2002 23:55
 Subject: Re: 80386 out of GENERIC
  M. Warner Losh wrote:
   One problem with most 386 boxes is that they have very little memory.
   sysinstall is a big, bloated pig dog these days that takes more RAM
   than most 386 boxes have.  This is true also for many 486 boxes too.
   So even if 386 stuff were in the default kernel, you'd likely have
   other issues in making sysinstall work and have to do custom
   hacking...
 
  Add to this that Bosko's workaround for the CPU bug with PSE/PGE
  includes loading the kernel at 4M rather than 1M.

-- 
Insert your favourite quote here.
Erik Trulsson
[EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Will official-NVIDIA-driver for 4.7 work with -CURRENT ?

[Erik Trulsson]

On Fri, Nov 08, 2002 at 02:11:08PM +0100, Juan Francisco Rodriguez Hervella wrote:
 Hello,
 
 I've just seen the release of FreeBSD-NVIDIA driver for
 FreeBSD-4.7
 
 Will this driver work with -CURRENT ?¿
 
 PS: http://www.nvidia.com/view.asp?IO=freebsd_1.0-3203


The README file found at the above URL claims that:

quote
FreeBSD -STABLE versions older than 4.7 and FreeBSD -CURRENT are
not supported.
end quote

So I guess the answer is no.
It is of course possible that it might work anyway even if NVIDIA don't
support it but since a kernel module is involved and those are generally
not portable between major releases it is not very likely it will work.

-- 
Insert your favourite quote here.
Erik Trulsson
[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Please test PAUSE on non-Intel processors

[Erik Trulsson]

On Fri, May 24, 2002 at 10:25:53AM -0400, John Baldwin wrote:
 Hey gang, although Intel's document seems to claim that they tested
 proper operation of pause I'd like people with non-Intel processors
 to verify that it actually works.  Please compile the attached test
 program and run it.  The output should look like this:
 
  ./pt
 Testing PAUSE instruction:
 Register esp changed: 0xbfbff9fc - 0xbfbff9c0
 


Intel Pentium 166/MMX:
  Testing PAUSE instruction:
  Register esp changed: 0xbfbffad8 - 0xbfbffa9c

AMD 386sx/33:
  Testing PAUSE instruction:
  Register esp changed: 0xbfbffb20 - 0xbfbffae4


Both machines running 4.6-PRERELEASE



-- 
Insert your favourite quote here.
Erik Trulsson
[EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Another possible solution for non-sendmail users

[Erik Trulsson]

On Sat, Mar 30, 2002 at 07:12:52PM +0100, Dag-Erling Smorgrav wrote:
 Gregory Neil Shapiro [EMAIL PROTECTED] writes:
  Given that non-sendmail users will be inconvenienced when upgrading due to
  the 8.12 changes (need to change sendmail_enable from NO to NONE),
 
 Why?  It doesn't make any difference as long as one uses the
 mailwrapper stuff:

Yes, it does.

 
 des@des ~% grep sendmail /etc/rc.conf
 sendmail_enable=YES
 des@des ~% cat /etc/mail/mailer.conf
 #
 # Execute the Postfix sendmail program, named /usr/local/sbin/sendmail
 #
 sendmail/usr/local/sbin/sendmail
 send-mail   /usr/local/sbin/sendmail
 mailq   /usr/local/sbin/sendmail
 newaliases  /usr/local/sbin/sendmail
 
 So what's all this noise and racket about?

This assumes that the replacement sendmail binary accepts the same
options as the real sendmail. In particular the options that are used
by default in the rc* files.
This is not the case for qmail for example.
(And there the normal use is not to start it with sendmail_enable=YES
but rather from its own start file under /usr/local/etc/rc.d/ after
disabling sendmail with sendmail_enable=NO (now NONE), which I
think should be the standard behaviour for alternative MTAs.)

So, if one uses qmail this change does require you to modify the
sendmail_* options in /etc/rc.conf.  

-- 
Insert your favourite quote here.
Erik Trulsson
[EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: *_enable=YES behavior is bogus

[Erik Trulsson]

On Fri, Feb 01, 2002 at 02:47:30AM -0330, Paul Fardy wrote:

 These examples, _and_yours_, are examples that suggest that
 /etc/rc.conf has a fundamental principle that
 
   foo_enable=YES/NO
 
 is supreme. One can set up all the requisite parameters (e.g. you
 can create sendmail.cf, named.conf, tune inetd.conf, compile psm
 into the kernel or install any of various screen savers), yet one
 can still set an appropriate variable
 
   foo_enable=NO
 
 which will not enable the feature.

It will not enable it, no. Nor will the feature be disabled if it for
some reason already was enabled.


 
 Not enabling something is *not* the same thing as disabling it.
 
 But I think that the intent in /etc/rc.conf is that enable=NO
 _is_ the same thing as disabling it. You might say If that were


Consider that the actual code in the various rc* start scripts is
in most cases of the form:

if foo_enable==yes
  do stuff
else
  do nothing


Some cases are instead

if foo_enable==no
  do nothing
else
  do stuff



A cursory search found a total of one instance where foobar=NO actually
makes something happen, and it was not of the form foo_enable=NO

(The single exception I found is
tcp_extensions=NO)


For all other variables one can set in rc.conf foobar=NO means
do nothing.


Looking at the code the intent certainly seems to be foo_enable=NO
shouldn't do anything.




 the intent, they'd have used ___. What word should we use
 to  indicate the absolute YES or NO that some of us believe
 should be the simple correct interpretation?

foo_enabled=YES/NO  perhaps??

I.e. describing the desired state of the feature instead of the desired
action to be taken.


There are of course several people who feel that the current behaviour
is the intuitive and obviously correct interpretation and would prefer
not to have it changed.


-- 
Insert your favourite quote here.
Erik Trulsson
[EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: AMD AGP Bug

[Erik Trulsson]

On Thu, Jan 31, 2002 at 09:32:48PM +0100, Gérard Roudier wrote:
 
 
 On Thu, 31 Jan 2002, Jason Evans wrote:
 
  On Wed, Jan 30, 2002 at 11:14:48PM +0100, Gérard Roudier wrote:
  
   Linux can be fixed, but the useless writes of the existing Athlons from
   the very fast cache to the relatively very slow memory cannot. And all
   Athlon users may well pay this penalty under any OS...  unless we want to
   disable caching. :)
 
  Have you done benchmarks to show that the speculative writes are useless
  often enough to cause enough memory bus contention that overall performance
  is degraded, despite the speedups when the speculative writes are valid?
 
 I haven't done any benchmark of this sort, neither intend to do any since
 I haven't time for that. But I wrote in my email that my 2 Athlon systems
 worked fine and fast, just to indicate that for normal use I didn't see
 any performance problem at all.
 
  I
  suspect that AMD in fact performed such tests; otherwise they wouldn't have
  gone to the trouble of implementing speculative writes.
 
 The Athlon rewriting same value to cacheable memory under the knees of
 programmers looks a severe issue to me if it is true. Not only AGP memory
 can be affected. What about SMP, MMIO (if some cacheable mapping exists),
 etc...?

I am not familiar with the acronym MMIO is so I can't comment on that. 

In general though, having memoryspace used for memory-mapped I/O
devices (including AGP) marked as cacheable is a bad idea unless you
are very careful and know exactly what you are doing.


For SMP it shouldn't be any problem. Multi-CPU systems normally
run some cache-coherence protocol between themselves to make sure that
things like this is not a problem.


 
 In my opinion, OSes having some cacheable mapping to AGP memory is not the
 real problem. Just it has revealed the AMD issue.

It might be argued that there should be some cache-coherence protocol
between the CPU and the AGP device.  Not knowing how AGP is specified I
don't know if this interaction between the CPU and AGP is a bug or just
working as specified.  I suspect it is the latter though.



-- 
Insert your favourite quote here.
Erik Trulsson
[EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: libedit replacement for libreadline

[Erik Trulsson]

On Thu, Jul 19, 2001 at 02:01:31AM -0700, Kris Kennaway wrote:
 On Thu, Jul 19, 2001 at 01:37:16AM -0700, Terry Lambert wrote:
  Kris Kennaway wrote:
   a) libcrypt has been reunified for 7 months now; Peter did it last
   December.
  
  Someone needs to tell my newly installed 4.3 system this.
  
  4.3-RELEASE _did_ come out after that, right?
  
  I guess this wasn't MFC'ed?  It seems to _still_ not have
  been MFC'ed in my 4.3-STABLE (pre-4.4) branch, so I'm
  guessing my example will remain true for 4.4-RELEASE and
  4.5-RELEASE, as well, unless someone does something about
  it before then...
 
 Peter MFC'ed it a few weeks ago.

A few days ago is more like it.

(cvs log lib/libcrypto/Makefile gives the following:)

revision 1.24.2.4
date: 2001/07/16 03:28:26;  author: peter;  state: Exp;  lines: +11 -56
MFC: unify libscrypt/libdescrypt into libcrypt.





-- 
Insert your favourite quote here.
Erik Trulsson
[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: errno (46) - for FreeBSD 4.0 NFS server

[Erik Trulsson]

On Wed, Mar 22, 2000 at 12:04:55PM +0300, Grigory Kljuchnikov wrote:
 Thierry, thank you for the information, 
 but it's very bad that there isn't NFS locking in FreeBSD.
 I'm afraid I need to move my FreeBSD NFS server to Solaris
 for x86. 
 
 I don't understand why NFS locking isn't in FreeBSD. 
 Is it difficult in the implementation or are there another 
 global problems in the kernel (or in the native filesystem)?
 
 Who know when the NFS locking is planed to release in FreeBSD?
 
 


Actually I think that server side locking *is* implemented but client side
locking isn't.
'man 8 rpc.lockd' for more information.
(And 'man 5 rc.conf' for information on how to start it at bootup.




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: errno (46) - for FreeBSD 4.0 NFS server

[Erik Trulsson]

On Wed, Mar 22, 2000 at 03:46:12PM +0300, Grigory Kljuchnikov wrote:
 Thank you, Erik!
 
 I find rpc.lockd and start it manually. My test with NFS locking works right.
 But it don't start on boot by default if I enable NFS server in
 /stand/sysinstall and there is the comment in /etc/default/rc.conf
 for rpc_lockd_enable:
 
 rpc_lockd_enable="NO"  # Run NFS rpc.lockd (*broken!*) if nfs_server.
 
 Does the comment "(*broken!*)" mean that rpc.lockd doesn't work properly? 
 

To be honest I don't know. I haven't used it myself but only read the
manpages. (Since I only use NFS between FreeBSD boxes and they don't support
client-side locking it seems pointless to have it on the server.)

That comment does seem to imply that something is broken but then the
manpage really should say something about that. (This might of course
indicate that the manpage isn't in sync with reality.)

Somebody who knows what is up with rpc.lockd is welcome to comment.


 
 On Wed, 22 Mar 2000, Erik Trulsson wrote:
 
  On Wed, Mar 22, 2000 at 12:04:55PM +0300, Grigory Kljuchnikov wrote:
   Thierry, thank you for the information, 
   but it's very bad that there isn't NFS locking in FreeBSD.
   I'm afraid I need to move my FreeBSD NFS server to Solaris
   for x86. 
   
   I don't understand why NFS locking isn't in FreeBSD. 
   Is it difficult in the implementation or are there another 
   global problems in the kernel (or in the native filesystem)?
   
   Who know when the NFS locking is planed to release in FreeBSD?
   
   
  
  
  Actually I think that server side locking *is* implemented but client side
  locking isn't.
  'man 8 rpc.lockd' for more information.
  (And 'man 5 rc.conf' for information on how to start it at bootup.
  
  
 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message