Re: cdrecord for ATAPI burners available..

[Søren Schmidt]

It seems Thomas Quinot wrote:
 Le 2002-03-19, Søren Schmidt écrivait :
 
   gmake[1]: *** [TocParser.o] Error 1
  You need to have pccts installed to compile cdrdao
 
 I do, and as I mentioned in my first message, the compileation completed
 after a gmake distclean.

okies...

  These utils are ATA only (as the name implies), if our ports people
  wants to merge it into whats already there I wont complain :)
  That said I think the ATA only version covers more than a significant
  percentage of our userbase
  
 
 In which case I'll be more than happy to continue maintaining ATAPI/CAM
 as an alternative solution, which addresses 100% of our user base and
 does not impose any additional work upon application authors or port
 maintainers.

I thought there was work on this already ? Justin called for a timeout
to get it done the right way in CAM, I was sort of expecting to
hear about how that should integrate in the ATA/ATAPI world...

However, I will maintain the ATA/ATAPI only cd/fd/tape drivers as I have
a use for them, be it in the official sources or locally, that all depends
on how the cake is to be cut...

-Søren

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

Re: cvs commit: src/usr.bin/xinstall xinstall.c

[Ruslan Ermilov]

On Mon, Mar 18, 2002 at 03:26:13PM -0800, Dag-Erling Smorgrav wrote:
 des 2002/03/18 15:26:13 PST
 
   Modified files:
 usr.bin/xinstall xinstall.c 
   Log:
   Bump the cutoff mark for comparing files from 8 MB to 16 MB.
   
   Revision  ChangesPath
   1.48  +3 -1  src/usr.bin/xinstall/xinstall.c
 
OK, I think it's finally the time to borrow mmap(2) comparison in
chunks from OpenBSD (better viewed as -w diff):

%%%
Index: xinstall.c
===
RCS file: /home/ncvs/src/usr.bin/xinstall/xinstall.c,v
retrieving revision 1.48
diff -u -p -r1.48 xinstall.c
--- xinstall.c  18 Mar 2002 23:26:13 -  1.48
+++ xinstall.c  20 Mar 2002 09:26:11 -
@@ -74,12 +74,11 @@ static const char sccsid[] = From: @(#)
 #define MAP_FAILED ((void *)-1)/* from sys/mman.h */
 #endif
 
-#define MAX_CMP_SIZE   (16 * 1024 * 1024)
-
 #defineDIRECTORY   0x01/* Tell install it's a directory. */
 #defineSETFLAGS0x02/* Tell install to set flags. */
 #defineNOCHANGEBITS(UF_IMMUTABLE | UF_APPEND | SF_IMMUTABLE | SF_APPEND)
 #defineBACKUP_SUFFIX   .old
+#defineMAX_CMP_SIZE(16 * 1024 * 1024)
 
 struct passwd *pp;
 struct group *gp;
@@ -523,6 +522,8 @@ compare(int from_fd, const char *from_na
int to_fd, const char *to_name __unused, size_t to_len)
 {
char *p, *q;
+   size_t len, remainder;
+   off_t from_off, to_off;
int rv;
int done_compare;
 
@@ -530,48 +531,60 @@ compare(int from_fd, const char *from_na
if (from_len != to_len)
return 1;
 
-   if (from_len = MAX_CMP_SIZE) {
-   done_compare = 0;
-   if (trymmap(from_fd)  trymmap(to_fd)) {
-   p = mmap(NULL, from_len, PROT_READ, MAP_SHARED, from_fd, 
(off_t)0);
+   done_compare = 0;
+   if (trymmap(from_fd)  trymmap(to_fd)) {
+   /*
+* Compare two files being careful not to mmap
+* more than 8M at a time.
+*/
+   from_off = to_off = (off_t)0;
+   remainder = from_len;
+   while (!rv  remainder  0) {
+   len = MIN(remainder, 8 * 1024 * 1024);
+
+   p = mmap(NULL, len, PROT_READ, MAP_SHARED, from_fd, from_off);
if (p == (char *)MAP_FAILED)
goto out;
-   q = mmap(NULL, from_len, PROT_READ, MAP_SHARED, to_fd, 
(off_t)0);
+   q = mmap(NULL, len, PROT_READ, MAP_SHARED, to_fd, to_off);
if (q == (char *)MAP_FAILED) {
-   munmap(p, from_len);
+   munmap(p, len);
goto out;
}
 
-   rv = memcmp(p, q, from_len);
-   munmap(p, from_len);
-   munmap(q, from_len);
-   done_compare = 1;
-   }
-   out:
-   if (!done_compare) {
-   char buf1[MAXBSIZE];
-   char buf2[MAXBSIZE];
-   int n1, n2;
-
-   rv = 0;
-   lseek(from_fd, 0, SEEK_SET);
-   lseek(to_fd, 0, SEEK_SET);
-   while (rv == 0) {
-   n1 = read(from_fd, buf1, sizeof(buf1));
-   if (n1 == 0)
-   break;  /* EOF */
-   else if (n1  0) {
-   n2 = read(to_fd, buf2, n1);
-   if (n2 == n1)
-   rv = memcmp(buf1, buf2, n1);
-   else
-   rv = 1; /* out of sync */
-   } else
-   rv = 1; /* read failure */
-   }
-   lseek(from_fd, 0, SEEK_SET);
-   lseek(to_fd, 0, SEEK_SET);
+   rv = memcmp(p, q, len);
+   munmap(p, len);
+   munmap(q, len);
+
+   from_off += len;
+   to_off += len;
+   remainder -= len;
+   }
+   done_compare = 1;
+   }
+out:
+   if (!done_compare  from_len = MAX_CMP_SIZE) {
+   char buf1[MAXBSIZE];
+   char buf2[MAXBSIZE];
+   int n1, n2;
+
+   rv = 0;
+   lseek(from_fd, 0, SEEK_SET);
+   lseek(to_fd, 0, SEEK_SET);
+   while (rv == 0) {
+   n1 = read(from_fd, buf1, sizeof(buf1));
+   if (n1 == 0)
+   

Re: cdrecord for ATAPI burners available..

[Thomas Quinot]

Le 2002-03-20, Søren Schmidt écrivait :

 I thought there was work on this already ? Justin called for a timeout
 to get it done the right way in CAM, I was sort of expecting to
 hear about how that should integrate in the ATA/ATAPI world...

Well I have not heard of any specific requirements on that matter.

 However, I will maintain the ATA/ATAPI only cd/fd/tape drivers as I have
 a use for them, be it in the official sources or locally, that all depends
 on how the cake is to be cut...

Currently, the ATAPI/CAM patches can coexist peacefully with acd/ast/afd,
and it is my intention to keep it that way. :)

Thomas.

-- 
[EMAIL PROTECTED]

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

Re: cdrecord for ATAPI burners available..

[Søren Schmidt]

It seems Scott Long wrote:
 In the past you've objected to ATAPI-CAM on two grounds, fear that it
 won't be done right, and fear that it will add more work to yourself.  I
 think that there are enough highly intelligent people interested in the
 project that the first issue can be put to rest.  While I highly respect
 what you have done with this port, I think that you are eroding your
 defense of the second issue.  I fail to see how porting (and presumably
 maintaining) a multitude of CD utilities will be less work for you than
 allowing someone to put a CAM hook into your acd driver, and then
 sitting back as they maintain that work.

I released these mods (which was actually done over a year ago on a
contract, but I couldnt release them until now) just so people
experiencing problems could try that route. This could reveal
the problems that some has with burncd, and which I would like
to get fixed, even if the 'pure' ATAPI driver suite is to be
replaced with CAM (I have a use for it at least without CAM)..
I was trying to be helpfull here, so please take a deep breath
before accusing me of anything else..

 If you object to ATAPI-CAM, just come out and and admit it.  This isn't
 a battle of egos of wills, and nobody is trying to discredit your work. 
 You are a valuable member of the FreeBSD community, and everybody
 appreciates the work that you have put it.  ATAPI-CAM is not meant to
 replace you, since we still need your expertise in every other part of
 the ATA/ATAPI/IDE framework.  It is meant to help users who want a
 simple way to do cool stuff with their ATAPI devices.

I have said repeatedly on these lists, that I have no problem with CAM
as long as the integration is done in a sensible way, and that I am
not the one to maintain the CAM translation layer.
I was under the impression that Justin was working with you guys on
how to do this right from the CAM perspective, at least that was the
way I interpreted his mail to this list. I'm not the one slowing
things down here, so please point your flak in another direction :)

However, the 'pure' ATAPI drivers will continue to live since I have
uses for it, if its not to be in the official sources, thats something
I'll have to consider how to handle then...

-Søren

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

Re: cdrecord for ATAPI burners available..

[Søren Schmidt]

It seems Thomas Quinot wrote:
 Le 2002-03-20, Søren Schmidt écrivait :
 
  I thought there was work on this already ? Justin called for a timeout
  to get it done the right way in CAM, I was sort of expecting to
  hear about how that should integrate in the ATA/ATAPI world...
 
 Well I have not heard of any specific requirements on that matter.

Me neither, maybe somebody should ping Justin on this..

  However, I will maintain the ATA/ATAPI only cd/fd/tape drivers as I have
  a use for them, be it in the official sources or locally, that all depends
  on how the cake is to be cut...
 
 Currently, the ATAPI/CAM patches can coexist peacefully with acd/ast/afd,
 and it is my intention to keep it that way. :)

Well, since Justin is MrCAM I think we should at least wait for him
to comment on this before spending too much work on it to find that 
it should be done differently. 

And yes, I'm all for coexistance as I've stated several times...

-Søren

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

[no subject]

[Kasatkin]

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

XFree86 4.2.0 with G200 fail to start with signal 10

[Riccardo Torrini]

With last update of world and ports I'm unable to start XFree86.
I have a matrox G200 (agp) and I have tryed with and without the
WITH_MATROX_GXX_DRIVER=yes but I got only a signal 10, core dump
when starting X.  At the same time I switched my MoBo from tyan
trinity with k6 to a asus p2b-ds dual processor p3/500.
I have a recent system (fresh compile with SMP enabled):

# uname -v
FreeBSD 5.0-CURRENT #24: Sun Mar 17 00:32:04 CET 2002

and I double check all update cycle (make update, buildworld,
buildkernel, installkernel, installworld, mergemaster, reboot)

I removed also _all_ ports and reinstalled them.
Also tryed to recreate a config for XFree from screatch but it
crash always with signal 10 (and sometimes with signal 6).

At this time I am not sure where is (can be?) the problem, mobo,
graphic card, -current or xfree.  Any hint?


TIA,
Riccardo.

PS: My previous message with ACPI info get lost, neither bounced
nor accepted.  And I am using correct local masquerading and my
ISP that has record for reverse resolution also.  Spam from .kr
instead is accepted to list.  Exists any other method for _serious_
user/tester to send to list?  Thanks again.

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

Re: Unexpected Soft Update Inconsistency

[Crist J. Clark]

On Wed, Mar 20, 2002 at 07:20:52AM +0100, Poul-Henning Kamp wrote:
 
 Sounds like your disklabel is smaller than your filesystem ?

Huh. That's what it looks like. How'd that happen?(tm) I don't
recall ever touching the disklabel since the install.

Oh, well. There was enough spare room on the disk to do a bare-bones
OS install on an open slice, backed up the bad filesystem and the
others on the slice, repartitioned the slice a little better now that
I have a feel for how the system will be used, newfs'ed all of the
partitions, and restored.

 In message [EMAIL PROTECTED], Crist J. Clark writes
 :
 I've got a -CURRENT system that is seriously resisting attempts to
 revive it. No matter how many times I run fsck(8), it tells me,
 
 ** /dev/ad0s1a
 ** Last Mounted on /
 ** Root file system
 ** Phase 1 - Check Blocks and Sizes
 
 CANNOT READ BLK: 8407744
 UNEXPECTED SOFT UPDATE INCONSISTENCY
 
 CONTINUE? yes
 
 THE FOLLOWING DISK SECTORS COULD NOT BE READ: 8407744, 8407745, 8407746, 8407747, 
8407748, 8407749, 8407750, 8407751, 8407752, 8407753, 8407754, 8407755, 8407756, 
8407757, 8407758, 8407759,
 ** Phase 2 - Check Pathnames
 ** Phase 3 - Check Connectivity
 ** Phase 4 - Check Reference Counts
 ** Phase 5 - Check Cyl groups
 133720 files, 1429523 used, 2651122 free (34074 frags, 327131 blocks, 0.8% 
fragmentation)
 
 * FILE SYSTEM STILL DIRTY *
 
 * PLEASE RERUN FSCK *
 
 There are no reports of hard errors, so I believe this is purely a
 soft error. Any advice on how to fix?
 -- 
 Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
 http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with unsubscribe freebsd-current in the body of the message
 
 
 -- 
 Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
 [EMAIL PROTECTED] | TCP/IP since RFC 956
 FreeBSD committer   | BSD since 4.3-tahoe
 Never attribute to malice what can adequately be explained by incompetence.

-- 
Crist J. Clark | [EMAIL PROTECTED]
   | [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]

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

i386/boot2.c patches

[Pierre Beyssac]

Would anyone mind if I commit the following to i386/boot2.c?
I've reviewed and tested them.

add -n option to boot2 to disallow user interruption
http://www.FreeBSD.org/cgi/query-pr.cgi?pr=36016

boot2 cleanup (modulo style(9) and a minor typo in a comment):
http://www.FreeBSD.org/cgi/query-pr.cgi?pr=36015
-- 
Pierre Beyssac  [EMAIL PROTECTED]

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

Re: rtld messing up?

[John Polstra]

In article [EMAIL PROTECTED],
Terry Lambert  [EMAIL PROTECTED] wrote:
 John Polstra wrote:
  All I know is this:  The dynamic linker was working just fine for
  years.  Then we got a new version of binutils, and lots of problems
  started happening.  The dynamic linker wasn't changed -- binutils
  was.  I have no idea what got broken, but I kind of doubt that the
  bug is in the dynamic linker.
 
 The new binutils screws over some basic long-standing assumptions
 about field ordering and associativity in the object files, which
 are no longer maintained (for whatever reason) in the new version
 of the tools.
 
 Some of them have been identified and repaired (e.g. the Alpha
 code changes for the section/segment order assumption), but it
 is going to probably be a long battle.
 
 Technically, the ELF spec permits the ordering, so the assumptions
 are really broken, even though they code for what's really a
 defacto-standard of many years, now.  8-(.

Can you be more specific?  To the best of my knowledge, I made no
assumptions beyond what the spec promised.  The only exception is that
the dynamic linker relies on the program header being in the first
page of the file, an assumption shared by the kernel as well.  I don't
think that assumption is wrong, or nothing would run at all.

John
-- 
  John Polstra
  John D. Polstra  Co., Inc.Seattle, Washington USA
  Disappointment is a good sign of basic intelligence.  -- Chögyam Trungpa


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

Re: rtld messing up?

[Mark Murray]

  Technically, the ELF spec permits the ordering, so the assumptions
  are really broken, even though they code for what's really a
  defacto-standard of many years, now.  8-(.
 
 Can you be more specific?  To the best of my knowledge, I made no
 assumptions beyond what the spec promised.  The only exception is that
 the dynamic linker relies on the program header being in the first
 page of the file, an assumption shared by the kernel as well.  I don't
 think that assumption is wrong, or nothing would run at all.

I'm going to sound like a prat here, mostly because I don't know
what I'm talking about. :-)

In ports/lang/gcl, a program is undumped, and the resultant binary
dumps core _very_ early in the startup. I can't get debugging info,
because the undumping also seems to strip the program.

Could you please try that port, and see what you can glean? I'm
frobbing around in xemacs, which works, to see if I can't fix
undump.

M
-- 
o   Mark Murray
\_
O.\_Warning: this .sig is umop ap!sdn

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

Re: rtld messing up?

[Miguel Mendez]

On Wed, Mar 20, 2002 at 05:47:32PM +, Mark Murray wrote:
 In ports/lang/gcl, a program is undumped, and the resultant binary
 dumps core _very_ early in the startup. I can't get debugging info,
 because the undumping also seems to strip the program.

I've also have had that same problem when I tried to build the port,
but was never able to find the reason for the program to segfault, I
even opened a PR on that. The program seems to work on NetBSD btw. 

Cheers,
-- 
Miguel Mendez - [EMAIL PROTECTED]
GPG Public Key :: http://energyhq.homeip.net/files/pubkey.txt
EnergyHQ :: http://www.energyhq.tk
FreeBSD - The power to serve!



msg36393/pgp0.pgp
Description: PGP signature

Re: more -current testers

[Marc van Woerkom]

 In my environment, I have a central build and file server, and then a
 series of network booted crash machines.

Hey, this is interesting. 

I planed to buy a serial terminal or simple pc which plays terminal for
quite a long time, but delayed that until I will have moved to the new 
appartment, where my wife won't kill me for adding another ugly pc :-)

That original scenario would mean I would use the second terminal box 
as work station to monitor and operate the main box.

This network scenario reverses roles: the existing comfortable box
would stay work station and used to inspect bare network boxes that just 
feature cpu, ram, and ethernet. A cheap solution and they could be 
hidden in the closet. 


 It's possible to replace the kernel out from under a machine while still
 crashing/dumping/rebooting.  This can dramatically reduce the
 develop/compile/install/test/crash/repeat cycle by coallescing the test
 and crash bits with the other bits, since you can compile while still
 testing or crashing.

Thats sounds interesting.


 Occasional PXE bugs can be very frustrating.  Some machines I've used have
 no problem loading pxeboot from a different machine than the DHCP server.
 A couple of others ignore the server specification in the DHCP response
 and insist on trying to tftp pxeboot from the DHCP server.

Did you do a write up of your experiences?

Regards,
Marc

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

RE: i386/boot2.c patches

[John Baldwin]

On 20-Mar-2002 Pierre Beyssac wrote:
 Would anyone mind if I commit the following to i386/boot2.c?
 I've reviewed and tested them.
 
 add -n option to boot2 to disallow user interruption
   http://www.FreeBSD.org/cgi/query-pr.cgi?pr=36016

Looks fine to me.

 boot2 cleanup (modulo style(9) and a minor typo in a comment):
   http://www.FreeBSD.org/cgi/query-pr.cgi?pr=36015

Looks mostly ok to me.  Not entirely sure about the autoboot changes
as it looks weird to load(kname) right before you change what kname
is.  I think the logic must somehow be wrong there.

Might want to ask Robert Nordier for review.

-- 

John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve!  -  http://www.FreeBSD.org/

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

Re: rtld messing up?

[Mark Murray]

  In ports/lang/gcl, a program is undumped, and the resultant binary
  dumps core _very_ early in the startup. I can't get debugging info,
  because the undumping also seems to strip the program.
 
 I've also have had that same problem when I tried to build the port,
 but was never able to find the reason for the program to segfault, I
 even opened a PR on that. The program seems to work on NetBSD btw.=20

PR ports/34661 :-)

M
-- 
o   Mark Murray
\_
O.\_Warning: this .sig is umop ap!sdn

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

Re: XFree86 4.2.0 with G200 fail to start with signal 10

[Will Andrews]

On Wed, Mar 20, 2002 at 11:29:46AM +0100, Riccardo Torrini wrote:
 With last update of world and ports I'm unable to start XFree86.
 I have a matrox G200 (agp) and I have tryed with and without the
 WITH_MATROX_GXX_DRIVER=yes but I got only a signal 10, core dump
 when starting X.  At the same time I switched my MoBo from tyan
 trinity with k6 to a asus p2b-ds dual processor p3/500.
 I have a recent system (fresh compile with SMP enabled):

What is your pkg_info -Ia?
I committed an updated version of the Matrox driver for
XFree86-4-Server, maybe you don't have that?  BTW, it's not very
well tested and I certainly can't test it myself w/o Matrox
hardware.

Regards,
-- 
wca

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

UFS2, GEOM DARPA - don't get all excited, OK ?

[Poul-Henning Kamp]

---BeginMessage---


Ok, Kirk and I thought it would stirr a buzz once we even mentioned
UFS2 so let me set the record straight, (or at least firmly crooked):

UFS2 is UFS Extended Attributes in the inodes.

That's it.  No more, no less.

In particular that means: No journaling.  No Btree-directories,
no in-directory inodes.

Because we need to increase the size of the inode we chose to run
a revision and call it UFS2, and obviously, we will make sure all
relevant fields get the space they need, or at reserve space for
their growth as part of this.  Specifically inode numbers, block
numbers and time_t will have 64 bit available.

We may attempt a couple of neat tricks at the same time: per inode
blocksize and lazy inode initializtion.  The former might improve
I/O performance down the road, the latter speed up newfs and fsck.

We will try to avoid forking sys/ufs/ufs if we can, we may have
to push some stuff from ufs to ffs to make that happen.

In practice this also means a sweep through all the userland stuff
to make it work with UFS2: newfs, fsck, tunefs, quotactl, sysinstall
etc (that's largely going to be my problem).

Incidently there is a not insignificant crossover between UFS and
disklabels and from there into GEOM, so some of the things I will
be doing in that corner will be hard to attribute only to one or
the other of these two DARPA funded projects.

The one thing we RSN will cry to have is endian/wordsize agnostic
UFS.  That is not part of the DARPA project description and it is
unlikely to sneak into it.  We have it in mind though.  (The
NETBSD work is not uninteresting, but both Kirk and I feel that
there might be a better and even more general solution.)

And this is yet a problem with significant crossover to the issues
I have in GEOM with reading labeling data structures of disks in
alien formats so some of the technology I plan for GEOM might be
applicable to UFS as well.


Finally, If you are in the US and you think it is a good thing that
DARPA sponsors stuff like this, don't forget to say so to people
who might, directly or indirectly, provide feedback to DARPA.

I hope this answers the FAQ on UFS2, GEOM and all that.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

---End Message---

Re: cvs commit: src/usr.bin/xinstall xinstall.c

[Bruce Evans]

On Wed, 20 Mar 2002, Ruslan Ermilov wrote:

 On Mon, Mar 18, 2002 at 03:26:13PM -0800, Dag-Erling Smorgrav wrote:
  des 2002/03/18 15:26:13 PST
 
Modified files:
  usr.bin/xinstall xinstall.c
Log:
Bump the cutoff mark for comparing files from 8 MB to 16 MB.
 
Revision  ChangesPath
1.48  +3 -1  src/usr.bin/xinstall/xinstall.c
 
 OK, I think it's finally the time to borrow mmap(2) comparison in
 chunks from OpenBSD (better viewed as -w diff):

Using mmap(2) at all is over-engineered IMO.  Does it make even 1 1%
difference for heavy uses like installworld?  I get the following times
on an Athlon1600 for installing an 8MB file 16 times after it has
already been installed and caches warmed up:

install -C:0.48 real 0.38 user 0.09 sys
install -MC:   0.86 real 0.26 user 0.59 sys

and for installing a copy of /usr/bin/*:

install -C:0.29 real 0.24 user 0.04 sys
install -MC:   0.54 real 0.10 user 0.42 sys

Using mmap(2) in cmp(1) makes more difference because the non-mmap
case of cmp(1) is poorly implemented.  cmp(1) uses a getc() loop, but
install(1) reads MAXBSIZE at a time).

 %%%
 Index: xinstall.c
 ===
 RCS file: /home/ncvs/src/usr.bin/xinstall/xinstall.c,v
 retrieving revision 1.48
 diff -u -p -r1.48 xinstall.c
 --- xinstall.c18 Mar 2002 23:26:13 -  1.48
 +++ xinstall.c20 Mar 2002 09:26:11 -
 @@ -74,12 +74,11 @@ static const char sccsid[] = From: @(#)
 ...
 +out:
 + if (!done_compare  from_len = MAX_CMP_SIZE) {
 + char buf1[MAXBSIZE];
 + char buf2[MAXBSIZE];
 + int n1, n2;

This is cleaner than before, but still has style bugs (nested declarations),
and still attempts to pessimize the !mmap case by using misaligned buffers
(copy() is missing the style bugs but not the misaligment attempt).

 ...
   } else
   rv = 1; /* don't bother in this case */

We should bother now, to give the documented semantics for -C (remove the
from_len = MAX_CMP_SIZE check above).

Bruce


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

Re: i386/boot2.c patches

[Thomas Quinot]

Le 2002-03-20, John Baldwin écrivait :

 Looks mostly ok to me.  Not entirely sure about the autoboot changes
 as it looks weird to load(kname) right before you change what kname
 is.  I think the logic must somehow be wrong there.

But this is what is currently in the code (as I mentioned in the PR,
36015 is strictly a code clarification, with no functional change).
The load() function in boot2 ends with an exec() of the loaded binary.
It returns only if it has failed. The purpose of replacing kname
after load() has returned is to try to load /boot/kernel if we have
failed to load /boot/loader.

Thomas.

-- 
[EMAIL PROTECTED]

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

Good Music A Beautiful Daye

[[EMAIL PROTECTED]]

a definite listen to...mellow - post on audiosurge.com 

'the beautiful daye,' the debut album from soul singer and poet tyren [grfx], is the 
best cool out CD since sade's lover's rock. The album was created to bring the mood 
and set the moment, and it does with subtle soundscapes and great melodies. 'the 
beautiful daye' is must have for serious music collectors, of soul and downtempo 
music, or lovers of great music.

go out and buy this record? - rolling out magazine

'the beautiful daye' - best when played between 8pm  6am

available at all fine music stores and amazon.com

www.luv4art.com/tyren.htm

produced by craig knight and e. Joaquin of saturn return; tme pro; aztek  dj 
prosecutor; and scars for hardboiled entertainment.

info: [EMAIL PROTECTED] 
underground artworks entertainment

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

Building 5.0 on 4.5 Broken in xlint?

[Crist J. Clark]

Looks like the correct lib hints aren't being used in the buildworld?
Am I the only one? I'm setting MAKEOBJDIRPREFIX (properly, in the
environment).

=== usr.bin/xlint/llib
/c/home/obj/c/home/src/usr.bin/xlint/llib/../xlint/xlint -cghapbx -L /usr/libdata/lint 
-Cposix /c/home/src/usr.bin/xlint/llib/llib-lposix
/c/home/obj/c/home/src/usr.bin/xlint/llib/../xlint/xlint -cghapbx -L /usr/libdata/lint 
-Cstdc /c/home/src/usr.bin/xlint/llib/llib-lstdc
/usr/libexec/ld-elf.so.1: Shared object libc.so.5 not found
/usr/libexec/ld-elf.so.1: Shared object libc.so.5 not found
*** Error code 1
*** Error code 1
2 errors
*** Error code 2
1 error
*** Error code 2
1 error
*** Error code 2
1 error
*** Error code 2
1 error
*** Error code 2
1 error

-- 
Crist J. Clark | [EMAIL PROTECTED]
   | [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]

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

RE: Building 5.0 on 4.5 Broken in xlint?

Because I'm not a development only a sysadmin, 
the next workaround would not fit in your case. :)

Check out where you already have libc.so.t in /usr/obj/usr/src/lib/libc or
not.
If you have one, copy it into /usr/lib and 'make -DNOCLEAN buildworld' or
'buildkernel' again.
If you don't,  compile only libc.so.5 in  /usr/src/lib/libc. It will make
libc.so.5 
in /usr/obj blah,blah, tree... Now you have one... 


 -Original Message-
 === usr.bin/xlint/llib
 /c/home/obj/c/home/src/usr.bin/xlint/llib/../xlint/xlint 
 -cghapbx -L /usr/libdata/lint -Cposix 
 /c/home/src/usr.bin/xlint/llib/llib-lposix
 /c/home/obj/c/home/src/usr.bin/xlint/llib/../xlint/xlint 
 -cghapbx -L /usr/libdata/lint -Cstdc 
 /c/home/src/usr.bin/xlint/llib/llib-lstdc
 /usr/libexec/ld-elf.so.1: Shared object libc.so.5 not found
 /usr/libexec/ld-elf.so.1: Shared object libc.so.5 not found
 *** Error code 1
 *** Error code 1
 

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

securelevel_gt used incorrectly in kldload?

[Alexander N. Kabaev]

The following check added into kern_linker.c seems wrong somehow:

if (securelevel_gt(td-td_ucred, 0) == 0) {
error = EPERM;
goto out;
}

The last thing securelevel_gt does is to perform this check:
return (active_securelevel  level ? EPERM : 0);
i.e. it returns EPERM is securelevel restriction is violated.

Should above construct be rewritten as follows instead?

if ((error = securelevel_gt(td-td_ucred, 0)) != 0)
goto out;

The same bug is present in vfs_mount too.
--
Alexander Kabaev

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

Re: Building 5.0 on 4.5 Broken in xlint?

[Crist J. Clark]

On Thu, Mar 21, 2002 at 11:17:18AM +0900, À强ȣ wrote:
 Because I'm not a development only a sysadmin, 
 the next workaround would not fit in your case. :)
 
 Check out where you already have libc.so.t in /usr/obj/usr/src/lib/libc or
 not.
 If you have one, copy it into /usr/lib and 'make -DNOCLEAN buildworld' or
 'buildkernel' again.
 If you don't,  compile only libc.so.5 in  /usr/src/lib/libc. It will make
 libc.so.5 
 in /usr/obj blah,blah, tree... Now you have one... 

Well, yeah, I could do that, but I really don't want to put a
libc.so.5 in the -STABLE system. And I shouldn't be getting that
error.
-- 
Crist J. Clark | [EMAIL PROTECTED]
   | [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]

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

Re: Removing CSRG libm?

[Steve Kargl]

On Thu, Mar 21, 2002 at 12:33:45PM +1100, Bruce Evans wrote:
 On Wed, 20 Mar 2002, Steve Kargl wrote:
 
 I forgot about the missing __pure2 in math.h.  (It prevents gcc
 doing optimizations like moving sqrt(2) out of loops.) There is
 another thread on freebsd-standards about _MULTI_LIBM support.  I

I'm not subscribed to freebsd-standards.  Too many list, too
little time.  I guess I'll go browse the archive.

 want the errno support completely removed so that we have a chance
 of declaring math functions as __pure2 unconditionally.  But maybe
 we can't do this anyway, because math functions normally have the
 side effect of setting IEEE exception flags.  Can we do things like
 
 #ifpragma STDC FENV_ACCESS ON
 double sqrt(double);
 #else
 double sqrt(double) __pure2;
 #endif
 
 ?

I don't know.  I forgot about the libm PR until last
week when someone else posted about paranoi.c failing
several tests.  I decided to check into the quality
of libm and work on improvements.  I still have a lot to
learn.

I think we'll only be able to add __pure2 on a case 
by case basis.  For example, the POSIX sqrt(3) manpage states 

   An application wishing to check for error situations should set
   errno to zero and call feclearexcept(FE_ALL_EXCEPT) before calling
   these functions.  On return, if errno is non-zero or
   fetestexcept(FE_INVALID | FE_DIVBYZERO | FE_OVERFLOW |FE_UNDERFLOW)
   is non-zero, an error has occurred.

 
  Also, are functions missing in libm with respect to the
  C99 standard?  I would be willing to work on implementing
  these functions.
 
 Most are missing, if you count long double and complex support.  Only
 a few are, for double support.  I noticed some easy ones like
 isnormal() when I scanned the C99 draft standard today to check the
 status if infnan.3.

Garrett pointed me to the Open Group's docs.  I didn't know
the docs were available on-line.  Complex functions are
confined to complex.h.  I suppose we need to implement 
complex.h, but I'll probably concentrate on math.h.

-- 
Steve

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

Re: cvs commit: src/usr.bin/xinstall xinstall.c

[Dag-Erling Smorgrav]

Ruslan Ermilov [EMAIL PROTECTED] writes:
 OK, I think it's finally the time to borrow mmap(2) comparison in
 chunks from OpenBSD (better viewed as -w diff):

What are you waiting for?  Commit! :)

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]

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

Re: Removing CSRG libm?

[Bruce Evans]

On Sat, 16 Mar 2002, Steve Kargl wrote:

 A long time ago I submitted PR misc/17848 which
 removes CSRG libm sources.  The audit trail shows
 some commentary, but AFAICT nothing much has been
 done based on that commentary.   With the upcoming
 release of of 5.0, I think we should consider the
 removal od CSRG libm and the repo copying of msun
 to libm; otherwise we'll drag CSRG libm around
 until 6.0.

OK, I will remove libm after repo-copying the interesting parts of it
to libm.  I'm not sure about repo-copying msun back to libm.  It would
would only create a small mess because they have only one file in
common (the top-level Makefile).  In general, repo-copying back can't
be done without creating a large mess, because copying would clobber
all the old history.

Bruce


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

Re: Removing CSRG libm?

[Steve Kargl]

On Thu, Mar 21, 2002 at 10:19:13AM +1100, Bruce Evans wrote:
 On Sat, 16 Mar 2002, Steve Kargl wrote:
 
  A long time ago I submitted PR misc/17848 which
  removes CSRG libm sources.  The audit trail shows
  some commentary, but AFAICT nothing much has been
  done based on that commentary.   With the upcoming
  release of of 5.0, I think we should consider the
  removal od CSRG libm and the repo copying of msun
  to libm; otherwise we'll drag CSRG libm around
  until 6.0.
 
 OK, I will remove libm after repo-copying the interesting parts of it
 to libm.  I'm not sure about repo-copying msun back to libm.  It would
 would only create a small mess because they have only one file in
 common (the top-level Makefile).  In general, repo-copying back can't
 be done without creating a large mess, because copying would clobber
 all the old history.
 

Bruce,

I re-read the audit trail of the PR.  You list two items:
gamma() should become tgamma(); and, (lack of) the use
of __pure2.  I was planning to compare our msun against
NetBSD and merge any appropriate changes (if any exists).
Do you have any patches for msun that you might commit
in the future?

Also, are functions missing in libm with respect to the
C99 standard?  I would be willing to work on implementing
these functions.

-- 
Steve

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

Re: Removing CSRG libm?

[Bruce Evans]

On Wed, 20 Mar 2002, Steve Kargl wrote:

 I re-read the audit trail of the PR.  You list two items:
 gamma() should become tgamma(); and, (lack of) the use
 of __pure2.  I was planning to compare our msun against
 NetBSD and merge any appropriate changes (if any exists).
 Do you have any patches for msun that you might commit
 in the future?

I created tgamma() from the BSD gamma() and will commit after a
repo-copy.  The changes are simple, and  clean enough except
gamma.c needs parts of exp.c and log.c.

I forgot about the missing __pure2 in math.h.  (It prevents gcc
doing optimizations like moving sqrt(2) out of loops.) There is
another thread on freebsd-standards about _MULTI_LIBM support.  I
want the errno support completely removed so that we have a chance
of declaring math functions as __pure2 unconditionally.  But maybe
we can't do this anyway, because math functions normally have the
side effect of setting IEEE exception flags.  Can we do things like

#ifpragma STDC FENV_ACCESS ON
double sqrt(double);
#else
double sqrt(double) __pure2;
#endif

?

 Also, are functions missing in libm with respect to the
 C99 standard?  I would be willing to work on implementing
 these functions.

Most are missing, if you count long double and complex support.  Only
a few are, for double support.  I noticed some easy ones like
isnormal() when I scanned the C99 draft standard today to check the
status if infnan.3.

Bruce


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