Re: more endian.h breakage; patch included.
On Mon, 16 Oct 2000, Bruce Evans wrote: On Sun, 15 Oct 2000, Steve Kargl wrote: Actually, in this case the endian.h change exposed a bug if the wait(2) manpage is correct. In particular, sys/types.h is required to occur before sys/wait.h, which was missing in libdialog/prgbox.c and libc_r/uthread/uthread_wait4.c. It is strictly correct for POSIX.1-1990, but FreeBSD-2 never had the requirement until now. POSIX.1-200x is relaxing similar requirements (I'm not sure about this one), so it is too late to start enforcing it. Perhaps a good fix would be to include sys/types.h in endian.h so that the world will again build properly? Just a suggestion. Regards, Tony. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: **HEADS UP** /usr/include/netnatm/
brian I recently added the directory /usr/include/netnatm/ to brian BSD.include.dist, and the ppp build now depends on this. Would you please add netnatm to 'LDIRS' definition of src/include/Makefile ? Without this, "make buildworld" fails just like this, since no header file in src/sys/netnatm/ is installed. === usr.sbin/ppp rm -f .depend mkdep -f .depend -a-DHAVE_DES -I/usr/obj/usr/src/i386/usr/include () /usr/src/usr.sbin/ppp/atm.c:32: netnatm/natm.h: No such file or directory mkdep: compile failed See also: URL:ftp://current.jp.FreeBSD.org/pub/FreeBSD/snapshots/i386/5.0-CURRENT-20001016-JPSNAP.log -- - Makoto `MAR' MATSUSHITA To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: **HEADS UP** /usr/include/netnatm/
brian I recently added the directory /usr/include/netnatm/ to brian BSD.include.dist, and the ppp build now depends on this. Would you please add netnatm to 'LDIRS' definition of src/include/Makefile ? Without this, "make buildworld" fails just like this, since no header file in src/sys/netnatm/ is installed. Ah, thanks ! Done. -- - Makoto `MAR' MATSUSHITA -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: more endian.h breakage; patch included.
On Sun, 15 Oct 2000, Steven G. Kargl wrote: There is another patch needed in libdialog. No patches are needed in applications; endian.h should be unbroken. In what way ? ntohl() ntonl() were previously wrong to return u_long. They now return uint32_t (which requires sys/types.h). They *could* be changed to return u_int32_t, but this doesn't seem to be the best way forward. They *could* be changed to return unsigned, but I think this is worse than u_int32_t. I guess another alternative is to move the BYTE_ORDER into a different file and stop including endian.h from wait.h, but this seems wrong too. Bruce -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: usr.sbin/ppp breakage
=== usr.sbin/ppp rm -f .depend mkdep -f .depend -a-DHAVE_DES -I/usr/obj/usr/src/i386/usr/include /usr/src/usr.sbin/ppp/acf.c /usr/src/usr.sbin/ppp/arp.c /usr/src/usr.sbin/ppp/async.c /usr/src/usr.sbin/ppp/auth.c /usr/src/usr.sbin/ppp/bundle.c /usr/src/usr.sbin/ppp/cbcp.c /usr/src/usr.sbin/ppp/ccp.c /usr/src/usr.sbin/ppp/chap.c /usr/src/usr.sbin/ppp/chat.c /usr/src/usr.sbin/ppp/command.c /usr/src/usr.sbin/ppp/datalink.c /usr/src/usr.sbin/ppp/deflate.c /usr/src/usr.sbin/ppp/defs.c /usr/src/usr.sbin/ppp/exec.c /usr/src/usr.sbin/ppp/filter.c /usr/src/usr.sbin/ppp/fsm.c /usr/src/usr.sbin/ppp/hdlc.c /usr/src/usr.sbin/ppp/iface.c /usr/src/usr.sbin/ppp/ip.c /usr/src/usr.sbin/ppp/ipcp.c /usr/src/usr.sbin/ppp/iplist.c /usr/src/usr.sbin/ppp/lcp.c /usr/src/usr.sbin/ppp/link.c /usr/src/usr.sbin/ppp/log.c /usr/src/usr.sbin/ppp/lqr.c /usr/src/usr.sbin/ppp/main.c /usr/src/usr.sbin/ppp/mbuf.c /usr/src/usr.sbin/ppp/mp.c /usr/src/usr.sbin/ppp/pap.c /usr/src/usr.sbin/ppp/physical.c /usr/src/usr.sbin/ppp/pred.c /usr/sr! c/usr.sbin/ppp/probe.c /usr/src/usr.sbin/ppp/prompt.c /usr/src/usr.sbin/ppp/proto.c /usr/src/usr.sbin/ppp/route.c /usr/src/usr.sbin/ppp/server.c /usr/src/usr.sbin/ppp/sig.c /usr/src/usr.sbin/ppp/slcompress.c /usr/src/usr.sbin/ppp/sync.c /usr/src/usr.sbin/ppp/systems.c /usr/src/usr.sbin/ppp/tcp.c /usr/src/usr.sbin/ppp/throughput.c /usr/src/usr.sbin/ppp/timer.c /usr/src/usr.sbin/ppp/tty.c /usr/src/usr.sbin/ppp/tun.c /usr/src/usr.sbin/ppp/udp.c /usr/src/usr.sbin/ppp/vjcomp.c /usr/src/usr.sbin/ppp/nat_cmd.c /usr/src/usr.sbin/ppp/atm.c /usr/src/usr.sbin/ppp/id.c /usr/src/usr.sbin/ppp/chap_ms.c /usr/src/usr.sbin/ppp/radius.c /usr/src/usr.sbin/ppp/i4b.c /usr/src/usr.sbin/ppp/ether.c /usr/src/usr.sbin/ppp/atm.c:32: netnatm/natm.h: No such file or directory mkdep: compile failed *** Error code 1 This should now be fixed, but a ``make world'' is required. -- Steve -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
random fallback init
The problem that when random device was not seeded, boot simply hangs (on
ldconfig! why?) Ugly init(8) gives no chance to stop booting and fall to
reboot or single mode again via ctrl-alt-del or another key combination;
sleeping on "rndblk" channel in ldconfig is not interruptible; only DDB or
Reset button save, with respective results as fsck need;(
Patch below is not simply patch (I suppose Mark Murray is good programmer,
and I am too lame to learn him how to program), but quick (and dirty?)
realization of requirement that random device must work even when it was not
seeded externally, and it works in patched variant at my system:
==={{{ screenshot part
Starting final network daemons:.
setting ELF ldconfig path: /usr/lib /usr/lib/compat /usr/X11R6/lib /usr/local/li
b
random_read: no seed yet, provide fallback
setting a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout /usr/X11R6/lib/a
out
starting standard daemons: cron sendmail sshd.
===}}}
Of course, it should be combined with patch of /etc/rc (see letter to -current:
`From: Doug Barton [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]').
diff -rNu src.orig/sys/dev/random/randomdev.c src/sys/dev/random/randomdev.c
--- src.orig/sys/dev/random/randomdev.c Sat Oct 14 13:59:54 2000
+++ src/sys/dev/random/randomdev.c Mon Oct 16 11:07:29 2000
@@ -113,7 +113,11 @@
error = EWOULDBLOCK;
}
else {
- if (random_state.seeded) {
+ if (!random_state.seeded) {
+ printf("random_read: no seed yet, provide fallback\n");
+ reseed(FAST);
+ }
+ if (1) {/* if(random_state.seeded) was here */
c = min(uio-uio_resid, PAGE_SIZE);
random_buf = (void *)malloc(c, M_TEMP, M_WAITOK);
while (uio-uio_resid 0 error == 0) {
@@ -122,8 +126,6 @@
}
free(random_buf, M_TEMP);
}
- else
- error = tsleep(random_state, 0, "rndblk", 0);
}
return error;
}
diff -rNu src.orig/sys/dev/random/yarrow.c src/sys/dev/random/yarrow.c
--- src.orig/sys/dev/random/yarrow.cSat Oct 14 13:59:54 2000
+++ src/sys/dev/random/yarrow.c Mon Oct 16 11:02:17 2000
@@ -268,7 +268,7 @@
#endif
}
-static void
+void
reseed(int fastslow)
{
/* Interrupt-context stack is a limited resource; make large
@@ -355,9 +355,6 @@
/* 7. Dump to seed file */
/* XXX Not done here yet */
- /* Release the reseed mutex */
- mtx_exit(random_reseed_mtx, MTX_DEF);
-
#ifdef DEBUG
printf("Reseed finish\n");
#endif
@@ -367,6 +364,9 @@
selwakeup(random_state.rsel);
wakeup(random_state);
}
+
+ /* Release the reseed mutex */
+ mtx_exit(random_reseed_mtx, MTX_DEF);
}
diff -rNu src.orig/sys/dev/random/yarrow.h src/sys/dev/random/yarrow.h
--- src.orig/sys/dev/random/yarrow.hSat Oct 14 13:59:54 2000
+++ src/sys/dev/random/yarrow.h Mon Oct 16 11:02:32 2000
@@ -46,6 +46,7 @@
void random_init_harvester(void (*)(struct timespec *, void *, u_int, u_int, u_int,
enum esource), u_int (*)(void *, u_int));
void random_deinit_harvester(void);
void random_set_wakeup_exit(void *);
+void reseed(int);
u_int read_random_real(void *, u_int);
void write_random(void *, u_int);
/netch
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: more endian.h breakage; patch included.
On Mon, 16 Oct 2000, Brian Somers wrote: On Sun, 15 Oct 2000, Steven G. Kargl wrote: There is another patch needed in libdialog. No patches are needed in applications; endian.h should be unbroken. In what way ? endian.h shouldn't depend on sys/types.h or include sys/types.h and its associated namespace pollution. It never did before. ntohl() ntonl() were previously wrong to return u_long. Not wrong. They have always been documented to return u_long. They now return uint32_t (which requires sys/types.h). In NetBSD and in FreeBSD for all arches except i386's they return in_addr_t which happens to be u_int32_t. They *could* be changed to return u_int32_t, but this doesn't seem to be the best way forward. I agree that it's not the best way forward, but u_int32_t is traditional namespace pollution in sys/types.h, so using it is safer than using uint32_t. They *could* be changed to return unsigned, but I think this is worse than u_int32_t. It is no different for an arch where unsigned is u_int32_t (both conflict with the man page :-). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Which GCC in CURRENT? [Was: Re: Wine update]
Szilveszter Adam wrote:
Hmmm. It is good that the problem got resolved, but I take both 4.1 and
-CURRENT use the same gcc version... (2.95.2) Or am I missing something?
AFAIK, -CURRENT uses a snapshot of GCC 2.96 which may have some bugs.
It reports itself as 2.95.2.
There are two directories in CURRENT's src/contrib: gcc and gcc.295 (the former is
fresher). In src/gnu/{usr.bin|lib} appropriate Makefile.inc files set .PATH to
.../.../gcc.295.
There seems to be no way to switch to another GCC by editing just one line
somewhere.
Does anybody knows why there are two GCC in CURRENT?
Regards,
Konstantin.
--
* *Konstantin Chuguev - Application Engineer
* * Francis House, 112 Hills Road
* Cambridge CB2 1PQ, United Kingdom
D A N T E WWW:http://www.dante.net
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Which GCC in CURRENT? [Was: Re: Wine update]
On Mon, Oct 16, 2000 at 09:49:30AM +0100, Konstantin Chuguev wrote:
There are two directories in CURRENT's src/contrib: gcc and gcc.295 (the former is
fresher). In src/gnu/{usr.bin|lib} appropriate Makefile.inc files set .PATH to
.../.../gcc.295.
There seems to be no way to switch to another GCC by editing just one line
somewhere.
Does anybody knows why there are two GCC in CURRENT?
Because there is a planned upgrade of the gcc to 2.96 sometime in the
future. But the new gcc snapshot contained in that directory (which is also
refreshed sometimes) is not yet ready for prime time. A gcc upgrade is a
very delicate matter and must be planned carefully. Also, since 2.96 has not
even been released yet, I assume the maintainer (bruce, AFAIK) just makes
sure that it builds and compiles stuff OK and so by the time 5.0 will be
released and hopefully 2.96 too, we just have to push the button and it will
be there.
If you look closely enough, you can also see two parallel gdb trees and at
one time (before the upgrade to the latest release version) there also used
to be two binutils dirs. I think this very careful approach on the part of
the maintainer(s) makes sure that gcc (and binutils and libc) upgrades are
so painless on FreeBSD, while they can be a significant PITA on Linux
because of possible incompatibilities.
--
Regards:
Szilveszter ADAM
Szeged University
Szeged Hungary
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Which GCC in CURRENT? [Was: Re: Wine update]
On Mon, 16 Oct 2000, Szilveszter Adam wrote: Also, since 2.96 has not even been released yet, I assume the maintainer (bruce, AFAIK) just makes sure that it builds and compiles stuff OK and so by the time 5.0 will be released and hopefully 2.96 too, we just have to push the button and it will be there. I can assert, with utmost authority ;-), that GCC 2.96 will never be released by the GCC team. See http://gcc.gnu.org/ml/gcc-announce/2000/msg3.html. I think this very careful approach on the part of the maintainer(s) makes sure that gcc (and binutils and libc) upgrades are so painless on FreeBSD, while they can be a significant PITA on Linux because of possible incompatibilities. Upgrades are not painless at all on FreeBSD, because of some additional hacks you/we are using. See the following two PRs for examples that cost me quite some time each (and are still open): http://www.FreeBSD.org/cgi/query-pr.cgi?pr=20966 http://www.FreeBSD.org/cgi/query-pr.cgi?pr=21983 If the first PR is not resolved in time for the GCC 3.0 release process (which is not that far ahead), FreeBSD might even be dropped from the list of secondary evaluation platforms for GCC 3.0. :-( In any case, the bug does prevent regular GCC developers and testers from using FreeBSD -- not a good thing, either! :-( On the other hand, lately David O'Brien has submitted several patches for the FreeBSD ports to GCC, most (all?) of which have been reviewed and integrated quickly, so there is a good chance that the difference between the FreeBSD version of GCC and FSF GCC will be further reduced. :-) Should any of you have some time to spend, those two PRs I mentioned above are really critical. hinthint g Gerald -- Gerald "Jerry" [EMAIL PROTECTED] http://www.dbai.tuwien.ac.at/~pfeifer/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
fxp - no wake on lan anymore ?
After updating over the weekend to a recent current i noticed that it does not wake up on lan activity anymore. This - nice - feature worked fine with the Intel fxp card before (i can't even get into the machine now to cut and paste the bootmessage because it wakes no longer up ..) Is this a bug or a feature ? hellmuth -- Hellmuth MichaelisTel +49 40 55 97 47-70 HCS Hanseatischer Computerservice GmbHFax +49 40 55 97 47-77 Oldesloer Strasse 97-99 Mail hm [at] hcs.de D-22457 Hamburg WWW http://www.hcs.de To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
syscons
Hi, I have a question about syscons, and I was wondering if there were anyone out there who knew enough about the initialization sequence of syscons to answer... Basically, I'm trying to write a TGA driver around syscons, but TGA is a PCI card, and it seems, after having looked through the syscons code and the VGA driver, that syscons is better suited to ISA-style adapters, i.e., it absoultely has to call (tga/vga)_configure() very early in boot (i.e., before main()) to register adapters, and this registration requires a probe of adapters _before_ PCI services are available to do a probe of PCI adapters--is this true? If so, does anyone know of a nifty way around this conundrum? Andrew Miklic To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
error in pci_cfgreg.c
I got this error while compiling the last kernel: cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -D_KERNEL -include opt_global.h -elf -march=i686 -mpreferred-stack-boundary=2 ../../i386/pci/pci_cfgreg.c ../../i386/pci/pci_cfgreg.c: In function `pci_cfgregopen': ../../i386/pci/pci_cfgreg.c:95: dereferencing pointer to incomplete type ../../i386/pci/pci_cfgreg.c:99: dereferencing pointer to incomplete type ../../i386/pci/pci_cfgreg.c:100: dereferencing pointer to incomplete type ../../i386/pci/pci_cfgreg.c:100: sizeof applied to an incomplete type ../../i386/pci/pci_cfgreg.c:100: sizeof applied to an incomplete type ../../i386/pci/pci_cfgreg.c: At top level: ../../i386/pci/pci_cfgreg.c:139: warning: no previous prototype for `pci_cfgintr' ../../i386/pci/pci_cfgreg.c: In function `pci_cfgintr': ../../i386/pci/pci_cfgreg.c:150: increment of pointer to unknown structure ../../i386/pci/pci_cfgreg.c:150: arithmetic on pointer to an incomplete type ../../i386/pci/pci_cfgreg.c:151: dereferencing pointer to incomplete type ../../i386/pci/pci_cfgreg.c:151: dereferencing pointer to incomplete type ../../i386/pci/pci_cfgreg.c:153: dereferencing pointer to incomplete type ../../i386/pci/pci_cfgreg.c:153: dereferencing pointer to incomplete type ../../i386/pci/pci_cfgreg.c:157: dereferencing pointer to incomplete type machine/cpufunc.h:112: warning: inlining failed in call to `ffs' ../../i386/pci/pci_cfgreg.c:157: warning: called from here ../../i386/pci/pci_cfgreg.c:158: dereferencing pointer to incomplete type *** Error code 1 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fxp - no wake on lan anymore ?
From the keyboard of hm: After updating over the weekend to a recent current i noticed that it does not wake up on lan activity anymore. This - nice - feature worked fine with the Intel fxp card before (i can't even get into the machine now to cut and paste the bootmessage because it wakes no longer up ..) Is this a bug or a feature ? Following up on my own mail: its a bug! This version does not wake up the machine on lan traffic: $FreeBSD: src/sys/pci/if_fxp.c,v 1.97 2000/10/15 14:18:58 phk Exp $ while this version: $FreeBSD: src/sys/pci/if_fxp.c,v 1.85 2000/08/11 17:47:55 wpaul Exp $ does wake up the machine. The card is an original Intel fxp0: Intel Pro 10/100B/100+ Ethernet port 0xe000-0xe03f mem 0xec00-0xec0f ,0xec101000-0xec101fff irq 7 at device 11.0 on pci0 hellmuth -- Hellmuth MichaelisTel +49 40 55 97 47-70 HCS Hanseatischer Computerservice GmbHFax +49 40 55 97 47-77 Oldesloer Strasse 97-99 Mail hm [at] hcs.de D-22457 Hamburg WWW http://www.hcs.de To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
error in pci_cfgreg.c
Build kernel breaks in pci_cfreg.c : cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -D_KERNEL -include opt_global.h -elf -march=i686 -mpreferred-stack-boundary=2 ../../i386/pci/pci_cfgreg.c ../../i386/pci/pci_cfgreg.c: In function `pci_cfgregopen': ../../i386/pci/pci_cfgreg.c:95: dereferencing pointer to incomplete type ../../i386/pci/pci_cfgreg.c:99: dereferencing pointer to incomplete type ../../i386/pci/pci_cfgreg.c:100: dereferencing pointer to incomplete type ../../i386/pci/pci_cfgreg.c:100: sizeof applied to an incomplete type ../../i386/pci/pci_cfgreg.c:100: sizeof applied to an incomplete type ../../i386/pci/pci_cfgreg.c: At top level: ../../i386/pci/pci_cfgreg.c:139: warning: no previous prototype for `pci_cfgintr' ../../i386/pci/pci_cfgreg.c: In function `pci_cfgintr': ../../i386/pci/pci_cfgreg.c:150: increment of pointer to unknown structure ../../i386/pci/pci_cfgreg.c:150: arithmetic on pointer to an incomplete type ../../i386/pci/pci_cfgreg.c:151: dereferencing pointer to incomplete type ../../i386/pci/pci_cfgreg.c:151: dereferencing pointer to incomplete type ../../i386/pci/pci_cfgreg.c:153: dereferencing pointer to incomplete type ../../i386/pci/pci_cfgreg.c:153: dereferencing pointer to incomplete type ../../i386/pci/pci_cfgreg.c:157: dereferencing pointer to incomplete type machine/cpufunc.h:112: warning: inlining failed in call to `ffs' ../../i386/pci/pci_cfgreg.c:157: warning: called from here ../../i386/pci/pci_cfgreg.c:158: dereferencing pointer to incomplete type *** Error code 1 Rgds, Are Folkestad To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: error in pci_cfgreg.c
In message [EMAIL PROTECTED] Valentin Chopov writes: : I got this error while compiling the last kernel: Sorry about that. I committed some of mike's changes at his request and didn't manage to commit them all. I've fixed this now. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: error in pci_cfgreg.c
In message [EMAIL PROTECTED] Are Folkestad writes: : Build kernel breaks in pci_cfreg.c : I screwed up and didn't commit some bits. Please re cvsup and try again. Sorry about that. It is all in the service of cardbus. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Our kernel just got too big again. :)
David O'Brien wrote: On Sat, Oct 14, 2000 at 01:54:39PM -0700, Jordan Hubbard wrote: We've blown out the kern.flp image. Time for me to chop something out again, unless there are any other suggestions. :| Mind if I commit this patch? Index: dokern.sh === RCS file: /home/ncvs/src/release/scripts/dokern.sh,v retrieving revision 1.35 diff -u -r1.35 dokern.sh --- dokern.sh 2000/09/29 03:24:03 1.35 +++ dokern.sh 2000/10/14 22:55:45 @@ -72,7 +72,15 @@ -e '/SOFTUPDATES/d' \ -e '/MFS/d' \ -e '/NFS_ROOT/d' \ + -e '/ncr/d' \ -e '/atapist/d' \ + -e '/lpt/d' \ + -e '/ppi/d' \ + -e '/vpo/d' \ + -e '/ugen/d' \ + -e '/uhid/d' \ If you remove uhid, will you prohibit installing on an USB-only system? -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Our kernel just got too big again. :)
On 15-Oct-00 Wes Peters wrote: David O'Brien wrote: On Sat, Oct 14, 2000 at 01:54:39PM -0700, Jordan Hubbard wrote: We've blown out the kern.flp image. Time for me to chop something out again, unless there are any other suggestions. :| Mind if I commit this patch? Index: dokern.sh === RCS file: /home/ncvs/src/release/scripts/dokern.sh,v retrieving revision 1.35 diff -u -r1.35 dokern.sh --- dokern.sh 2000/09/29 03:24:03 1.35 +++ dokern.sh 2000/10/14 22:55:45 @@ -72,7 +72,15 @@ -e '/SOFTUPDATES/d' \ -e '/MFS/d' \ -e '/NFS_ROOT/d' \ + -e '/ncr/d' \ -e '/atapist/d' \ + -e '/lpt/d' \ + -e '/ppi/d' \ + -e '/vpo/d' \ + -e '/ugen/d' \ + -e '/uhid/d' \ If you remove uhid, will you prohibit installing on an USB-only system? No, but you already can't install on USB-only systems due to hokieness for USB keyboards. Intel UHCI controller USB keyboards don't work in the loader, so you can't hit Enter in between floppies, and due to the way they emulate older keyboards and the ugliness of the console probe, you won't have a usable keyboard once the system is booted. For OHCI controllers, you can't use the keyboard during the kernel userconfig stuff, though they work fine otherwise. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc "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
Release of 5.0
Just curious on the potential release of 5.0 -- which I presume won't be until next year.. ? _F To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /boot partition?
On Fri, Oct 13, 2000 at 07:22:20AM -0500, Mike Meyer scribbled: | Just curious - now that the kernel has moved into /boot/kernel/kernel, | does anyone know how well would it work to put /boot in it's own | partition (possibly in it's own slice)? I do not think loader can see stuff in other partitions. Nope, the loader can load stuff from other partitions, even from some strange ones like msdos ;), so theoretically it should be possible to have /boot, or even /boot/kernel, on another partition (it may require to tweak loader config files, though), but I really do not see any reasons behind such weird setup. I could have a 40G /, and not worry about the cylinder spanning problem, if my /boot were in a seperate (low) partition. I could have a / that was of an FS type not understood by the kernel, until after a module defining the FS type had been loaded. I could have a / that was on a controller for which I did not have a device comiled into my kernel, and only loaded it as a module from an FS type that it _did_ understand. Terry Lambert [EMAIL PROTECTED] --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /boot partition?
On Tue, 17 Oct 2000, Terry Lambert wrote: I could have a 40G /, and not worry about the cylinder spanning problem, if my /boot were in a seperate (low) partition. I could have a / that was of an FS type not understood by the kernel, until after a module defining the FS type had been loaded. I could have a / that was on a controller for which I did not have a device comiled into my kernel, and only loaded it as a module from an FS type that it _did_ understand. Terry Lambert [EMAIL PROTECTED] Garth, I think that was a haiku. -- Brandon D. Valentine [EMAIL PROTECTED] "Few things are harder to put up with than the annoyance of a good example." -- Mark Twain, Pudd'nhead Wilson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Our kernel just got too big again. :)
[ ... manual driver load from third floppy ... ] The problem with such an approach is that it's not very user-friendly to first-time installers who have no idea how to drive the loader. Let's not forget the linux installation floppy saga and all the confusion it's caused people just in trying to figure out which floppies to use. That would be where the forth hackery comes in - an additional set of menu options which make it a no-brainer to insert the kernel module floppy. Jordan's right. This is a non-starter, unless it says: "Please insert the optional drivers floppy now, and hit return. If you have no more optional drivers to load, please insert the root floppy now, and hit return." Ideally, the thing will be DOS formatted, and have a "\freebsd" directory, in which drivers are located, and a "\freebsd\drivers.ini" that contained name/value pairs indicating files to load and version(s) available. This would make it easy for the FreeBSD project to provide binary drivers which vendors could then just include some more files on their disks, since duplication costs won't change by adding more files, so long as they fit. A nice win, all around. Terry Lambert [EMAIL PROTECTED] --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Recent thread changes
In article
[EMAIL PROTECTED], Daniel
Eischen [EMAIL PROTECTED] wrote:
So far I read this as saying the sched_XXX functions operate on
processes, whereas the pthread_{set|get}schedparam functions operate
on threads.
Me too.
(4) When a running thread calls the sched_setparam() function,
the priority of the process specified in the function call is
modified to the priority specified by the param argument.
If the thread whose priority has been modified is a running
thread or is runnable, runnable thread [sic] it then becomes
the tail of the thread list for its new priority.
This contradicts itself and is where I think it is unclear. Where
does it state that the _threads_ priority is modified? It only
says that the process priority is modified. When it goes on to
say "If the thread whose priority has been modified...", it's
assuming something that was never stated as a requirement.
Agreed. I think they meant process, not thread. The whole section
has quite a few things I suspect are typos and/or editing errors.
(5) When a running thread calls the pthread_setschedparam()
function, the thread specified in the function call is
modified to the specified policy and the priority specified by
the param argument.
The above is a clearly stated requirement. If they had meant for
the threads priority to be changed by sched_setparam(), then it
should have been stated just as it has been above (5).
(6) If a thread whose policy or priority has been modified is
a running thread or is runnable, runnable thread [sic] it then
becomes the tail of the thread list for its new priority.
Unless it holds a priority protection or inheritence mutex, in
which case it gets added to the head of the thread list for its
new priority. This case is often forgotten (see 13.6.1.2).
I get the feeling they rushed this part into print after making a
lot of last-minute changes to it.
For this policy, valid priorities shall be within the range
returned by the function sched_get_priority_max() and
sched_get_priority_min() when SCHED_FIFO is provided as the
parameter.
So it seems clear that the same range of priorities shall apply to
individual threads as well as to processes. (SCHED_RR is similar in
these respects.)
For SCHED_FIFO and SCHED_RR, we don't have a problem because both
the threads library and kernel now agree that the range is 0..31.
SCHED_OTHER is a problem because the threads library treats
SCHED_OTHER as SCHED_RR with range 0..31. The kernel treats
SCHED_OTHER traditionally with range -20..20.
As long as the only problem area is SCHED_OTHER, we are arguably
OK. SCHED_OTHER is almost entirely implementation-defined; it can
do practically anything. More specifically, section 13.5.2.2 (the
detailed description of pthread_[sg]etschedparam) says:
The policy parameter may have the value SCHED_OTHER, SCHED_FIFO,
or SCHED_RR. The scheduling parameters for the SCHED_OTHER policy
are implementation defined. The SCHED_FIFO and SCHED_RR policies
shall have a single scheduling parameter sched_priority.
I think it would be slightly less surprising if our implementation of
SCHED_OTHER used thread priorities in the range -20..20 just the same
as processes. But in my opinion POSIX doesn't require that.
John
--
John Polstra [EMAIL PROTECTED]
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: Recent thread changes
[EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED], Daniel Eischen [EMAIL PROTECTED] wrote: For SCHED_FIFO and SCHED_RR, we don't have a problem because both the threads library and kernel now agree that the range is 0..31. SCHED_OTHER is a problem because the threads library treats SCHED_OTHER as SCHED_RR with range 0..31. The kernel treats SCHED_OTHER traditionally with range -20..20. As long as the only problem area is SCHED_OTHER, we are arguably OK. SCHED_OTHER is almost entirely implementation-defined; it can do practically anything. More specifically, section 13.5.2.2 (the detailed description of pthread_[sg]etschedparam) says: The policy parameter may have the value SCHED_OTHER, SCHED_FIFO, or SCHED_RR. The scheduling parameters for the SCHED_OTHER policy are implementation defined. The SCHED_FIFO and SCHED_RR policies shall have a single scheduling parameter sched_priority. I think it would be slightly less surprising if our implementation of SCHED_OTHER used thread priorities in the range -20..20 just the same as processes. But in my opinion POSIX doesn't require that. I tend to agree. When you consider that you can mix PTHREAD_SCOPE_SYSTEM threads with PTHREAD_SCOPE_PROCESS threads, it seems logical that you'd want the priority ranges in both the threads library and the kernel to agree. I would just rather see 0..31 instead of -20..20. We'll have to address this issue in the near future. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
