Re: comments on code-in tasks for FreeBSD (Re: FreeBSD + Google Code-In 2014 = we need ideas.)
On Thu, Nov 13, 2014 at 07:55:16PM -0800, Rui Paulo wrote: On Nov 13, 2014, at 17:40, Luigi Rizzo ri...@iet.unipi.it wrote: But please nuke the current list -- it is completely inadequate for the code-in candidates and misleading for whoever wants to suggest new tasks. Again i am not saying that the projects suggested there are not important, just belong somewhere else e.g. gsoc. I refrained from voicing my opinion while the call for help was going on, but I completely agree that the target age of this Google initiative is inadequate to FreeBSD. The target population is 13 years to 17 years old and I cannot even imagine a 13 year old knowing what FreeBSD is. ...and yet there was pat@ becoming a ports committer at the age of 16 and chris@ becoming a docs committer at the age of 14 :) I think hmp@, alepulver@, issyl0@ and jmallett@ were pretty young when they joined, too. Just an observation, I know that one or two isolated cases do not prove a point :) G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@freebsd.org p.penc...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: Digital signature
Re: ports include /etc/src.conf? i.e. graphics/libfpx
On Thu, Feb 14, 2013 at 01:55:58PM +, Tom Evans wrote: On Thu, Feb 14, 2013 at 1:12 PM, Mikhail T. mi+t...@aldan.algebra.com wrote: I may sound defensive here, but I'll still repeat, that this singular port (and I do, in fact, have other ones like it) started using bsd.lib.mk 5 years before src.conf (and its man-page) was added to the tree. -mi This is true. But what is the bug, that the port's Makefile.bsd was not updated on the introduction of src.conf to DTRT (and no-one noticed for 7 years), or that the purpose of src.conf has been mistakenly documented for 7 years? To be brutally honest, and at some cost to myself, I would have to say both :( There are some people - and some of them are well-respected long-term Free-and-other-BSD developers - who are of the opinion that the /usr/share/mk/bsd.*.mk infrastructure is meant for the base system build only. I do indeed understand this point of view - and from this point of view, the port's Makefile.bsd is buggy because it allegedly abuses internal parts of the base system. At the same time (see the last paragraph) I do quite understand the other point of view - that FreeBSD is not merely an operating system or a combination of an operating system and third-party software adapted to work on it consistently, but that it is a software distribution (what, after all, does BSD mean? :). Hence, its source code is meant to be adopted, adapted and used in everyone's software projects when everyone feels like it (under the conditions of the respective licenses, of course). If this is taken to mean that if we have bsd.*.mk, we are free to use it, then it will turn out that bsd.*.mk is not really an internal part of the base system, and that the documentation for src.conf maybe ought to mention that the settings there may affect the build of third-party programs that use the bsd.*.mk infrastructure (and of course there would be no way to list all such programs). However... However, there is then the argument of well, if you want to use the bsd.*.mk infrastructure, then why don't you just copy it into your project and include it from there - just like many, many projects do with, say, the sys/queue.h header, or parts of libc, or whatever? And it is, indeed, a very good argument, since this is how a software distribution's parts are supposed to be used - you copy them into your project and use them even when they are not available on the host system. So one might argue that the port is, indeed, buggy, that the src.conf documentation is, indeed, correct, and that the proper way for people to use the bsd.*.mk infrastructure in their own projects is to take a snapshot, remove the include /etc/rc.conf part, change the include statements to be relative to the current directory or something, and then include the bsd.*.mk files from their own project's source directory. I'm not sure if there are any projects that actually do that, but IMHO this is the correct way to do it :) Now, in this particular case, we have a slightly different situation when the code that uses the bsd.*.mk infrastructure is not part of the upstream software source code, but is part of the FreeBSD port - that is, it is supposed to work mostly on FreeBSD, and the port is supposed to keep up with the times and work around any incompatible bsd.*.mk changes. So... with all due respect to Mikhail, I do believe that in this case the port's Makefile.bsd ought to add the without src.conf definition before including the bsd.*.mk parts. The at some cost to myself part at the start of this message is because some of my released software uses the bsd.prog.mk/bsd.lib.mk infrastructure, with the unspoken assumption that I'll update it when the bsd.*.mk infrastructure changes in incompatible ways (this has not really happened for the past twelve years, mostly because my Makefiles do not try to use NO_MAN or similar options - they define everything they need, and it is not a whole lot :) So... yeah, I've been lazy, and yeah, some weird src.conf settings might confuse the build of some of my software on FreeBSD. And, of course, my software might very well not build at all on other BSD-like host platforms. But... yeah, well, I've been lazy ;) ...thanks for reading so far, I guess :) G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@freebsd.org p.penc...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 When you are not looking at it, this sentence is in Spanish. signature.asc Description: Digital signature
Re: using cupsd instead of base lpr
On Thu, Jun 24, 2010 at 03:56:56PM +0200, Dag-Erling Smørgrav wrote: Ed Schouten e...@80386.nl writes: In my opinion, we should just rename mailwrapper to whateverwrapper and list the lpr programs in there as well. Take a look at /etc/alternatives in any Debian-based Linux distro... Yeah, that's actually something I've long wondered about implementing; shouldn't be too hard, really. Never found the tuits, though :) For those who don't know what the idea is: /usr/bin/ftp is a symlink to /etc/alternatives/ftp, which in its turn is a symlink to /usr/bin/tnftp. The /etc/alternatives/ links are maintained by the update-alternatives utility which knows about priorities, defaults, slave symlinks (e.g. if the ftp(1) utility's symlink changes, it would be best to also change the ftp.1.gz manpage symlink, wouldn't it?), and a whole lot more. From a user's standpoint, all you have to do is install a package that declares a higher-priority alternative, and update-alternatives switches the symlink behind the scenes (unless you have explicitly specified one of the choices). If you don't like that, run update-alternatives by hand, and your choice is honored even if later a package with an even higher priority is installed. G'luck, Peter -- Peter Pentchev r...@space.bgr...@ringlet.netr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 Hey, out there - is it *you* reading me, or is it someone else? signature.asc Description: Digital signature
Re: Darwin/OSX Bluetooth code
On Thu, Oct 16, 2003 at 09:00:02PM -0700, Maksim Yevmenkin wrote: [snip] I'm currently thinking about un-Netgraph'ing FreeBSD code to make it portable to other BSD style systems. I'm trying to look at other implementations and learn as much as i can. In particular i'm trying to figure out how to minimize OS dependent code and what is the right abstractions levels. When I saw your BlueTooth entry in the recent status report, I thought I'd comment on that, but then got distracted :) You've done some great work on BlueTooth. IMHO, it would be a mistake to try to un-NetGraph it; there have been lots of rumours about people porting the NetGraph framework to other OS's, and if BlueTooth support will provide yet one more reason for the need to do this, so be it :) NetGraph is a wonderful framework for writing drivers, and not limited to network drivers, either - as you have no doubt discovered so far - there should be no need to give up its advantages if it's possible to retain them and even gain much in portability for the writing of future drivers (should NetGraph run on more OS's). G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence was in the past tense. pgp0.pgp Description: PGP signature
Re: HEADS UP: Be nice to -CURRENT ( 1 week Feature Slush )
On Fri, Mar 08, 2002 at 10:17:16AM -0600, David W. Chapman Jr. wrote: currently kde doesn't work due to binuntils update. It may work now after the most recent binutils update, but we have to recompile kde to see that I believe, andkdelibs cannot be compiled which builds kde-config which the rest of the kde meta-ports try to run. [snip] I'm not the only one that is experiencing it either, here is what I was told by Alan Eldridge [EMAIL PROTECTED] On Tue, Mar 05, 2002 at 05:26:27PM -0600, David W. Chapman Jr. wrote: When I try to build kdelibs2 I get the following under recent -current builds ,.deps/kextsock.pp -c kextsock.cpp -fPIC -DPIC -o .libs/kextsock.o kextsock.cpp: In method `struct kde_addrinfo * KExtendedSocketLookup::results()' : kextsock.cpp:294: implicit declaration of function `int __htons(...)' kextsock.cpp:353: implicit declaration of function `int __htonl(...)' Yes. Recent changes to netinet/in.h have made it require the inclusion of arpa/inet.h. As well, arpa/inet.h must include netinet/in.h. IOW, each of these files must #include the other in order to work correctly. As you might guess, this is a less than desirable situation. A #includes B and B #includes A is a very bad arrangement. However, unless both files are overhauled, that is what will have to happen. FWIW, Alan filed a PR about that - bin/35598. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 What would this sentence be like if it weren't self-referential? msg35804/pgp0.pgp Description: PGP signature
Re: XFree86-4 required?
On Fri, Oct 19, 2001 at 11:44:42AM -0700, David O'Brien wrote: On Thu, Oct 18, 2001 at 09:33:09PM +0200, Riccardo Torrini wrote: Is a real need for ports under -CURRENT to require (from a week or two, I don't remember) XFree86-libraries? Yes. To elaborate a bit, the default XFree86 version in -current was recently changed from 3 to 4. Thus, if you still want to go with your XFree86-3.x installation, you have to explicitly set XFREE86_VERSION to 3. G'luck, Peter -- This sentence no verb. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: problem with dynamic sysctls in -current
On Sun, Sep 09, 2001 at 09:49:59AM +0900, [EMAIL PROTECTED] wrote:
On Sat, Sep 08, 2001 at 10:27:10PM +0200, Christian Carstensen wrote:
hmm,
i've posted the attached mail a week ago to this list, but got no
response. could someone please comment on this issue?
I've also posted a patch(much less refined than yours, though) last month
but still got no response. Maybe you need to talk to the person who committed
rev 1.112 of kern_sysctl.c ?
Ouch! I was wondering why no one complained about the way I broke
dynamic module unloading.. Guess I don't read -current as much as
I should..
Anyway - yes, I am aware of the breakage that rev 1.112 introduced,
although I only became aware of it a week or so ago, when I tried
to MFC it to 4.4-RC.. I wrote up a quick patch to make things work
again, a short discussion on -arch followed, resulting in no real
agreement except for it's broken, somebody should fix it.
This, of course, is definitely not an appropriate way to end
a discussion about a FreeBSD kernel breakage, but I've been a bit
held up by real work events lately, and my -current system went
a-bye-bye due to unrelated issues, so I had no system to test any
kind of fixes on.
I am CC'ing this to Andrej Bialecki, who seems to know a bit more
than me about kern_sysctl.c; Andrej, is the attached patch good
enough to be committed as an interim fix, until somebody actually
gets around to fixing the sysctl_ctx_free() algorithm? This patch
is definitely way better than my hack, which added a bogus new
argument to sysctl_add_oid() :)
If there are no objections, I could commit this in the next few
days and take on the responsibility to really look into this in
a week or two, and really clean up the mess I made..
G'luck,
Peter
--
Nostalgia ain't what it used to be.
-- Forwarded message --
Date: Sat, 1 Sep 2001 03:26:46 +0200 (CEST)
From: Christian Carstensen [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: dynamic sysctl problem and proposed hot fix
hi,
i just came across a problem with dynamic sysctls:
when unloading a driver module that used dyn sysctls, my system paniced
with oid too high. that problem is caused by sysctl_ctx_free() in
kern/kern_sysctl.c, that first deregisters all oids in the list to see if
a error occurs. then, all oids are being reregistered and, if there was no
error, they're finally removed.
during the second phase, sysctl_register_oid(e1-entry) is called with
n := e1-entry-oid_number being the old oid number with n CTL_AUTO_START.
that leads to panic(static sysctl too high) in sysctl_register_oid.
one approach might be to initialize the oid_number field to contain the
value OID_AUTO before calling sysctl_regiser_oid, but i'm unsure about the
side effects of doing that in sysctl_ctx_free().
alternatively, the old oid number could be reused, the following patch
should do, but it's just a workaround.
best,
christian
--
Sorry, no defects found. Please try a different search
[http://www.cisco.com/support/bugtools/bugtool.shtml]
Index: kern_sysctl.c
===
RCS file: /usr/cvs/src/sys/kern/kern_sysctl.c,v
retrieving revision 1.113
diff -r1.113 kern_sysctl.c
83a84,96
static struct sysctl_oid *
sysctl_find_oidnumber(const int number, struct sysctl_oid_list *list)
{
struct sysctl_oid *oidp;
SLIST_FOREACH(oidp, list, oid_link) {
if (oidp-oid_number == number) {
return (oidp);
}
}
return (NULL);
}
125c138,139
panic(static sysctl oid too high: %d, oidp-oid_number);
---
if (sysctl_find_oidnumber(oidp-oid_number, parent))
panic(static sysctl oid too high: %d, oidp-oid_number);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src Makefile.inc1
On Tue, May 15, 2001 at 05:33:54PM +0300, Ruslan Ermilov wrote:
OK, more details on 4.3-STABLE - 5.0-CURRENT upgrade path breakage.
1. kbdcontrol(1) is used by usr.sbin/sysinstall/Makefile to generate
keymap.h with keyboard maps.
2. Recent usr.sbin/sysinstall/Makefile wants to generate keymap.h
from current keymap sources in ../../share/syscons/keymaps,
so it should use current kbdcontrol(1) as well because:
a) only -CURRENT kbdcontrol(1) understands ${KEYMAP_PATH}
b) only current kbdcontrol(1) may understand current keymap
file syntax, as is the keyboard paste feature for now.
3. So usr.sbin/kbdcontrol should be in Makefile.inc1:bootstrap-tools.
4. But bootstrap-tools are supposed to be built in a host environment,
and -CURRENT kbdcontrol(1) couldn't be built on -STABLE because it
requires -CURRENT sys/sys/kbio.h header (the PASTE define).
I'm currently testing with -I${.CURDIR}/../../sys added to the
kbdcontrol/Makefile, but this is a gross hack.
Can't you teach sysinstall/Makefile to use the kbdcontrol in
${.OBJDIR}/../kbdcontrol/kbdcontrol instead, and make it somehow
depend on kbdcontrol being built beforehand?
G'luck,
Peter
--
This sentence would be seven words long if it were six words shorter.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: LINT and NOTES
On Thu, Apr 19, 2001 at 12:23:54PM -0500, Will Andrews wrote: On Thu, Apr 19, 2001 at 10:23:02AM -0700, Jens Schweikhardt wrote: I just wanted to close http://www.freebsd.org/cgi/query-pr.cgi?pr=25030 by frobbing NOTES. While 4.2-R LINT has option USER_LDT, NOTES doesn't have it anymore. Can anybody clue me in why it disappeared? Can I simply resurrect it? Because peter eliminated it by making the relevant code mandatory about 2 months ago. Check out the cvs logs for NOTES. BTW, is this the right list to ask such a question? Nope. current@ would be. Here's Peter Wemm's commit, for reference purposes. G'luck, Peter -- When you are not looking at it, this sentence is in Spanish. Message-Id: [EMAIL PROTECTED] From: Peter Wemm [EMAIL PROTECTED] Date: Thu, 22 Feb 2001 17:25:02 -0800 (PST) To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: cvs commit: src/sys/conf options.i386 options.pc98 src/sys/i386/conf NOTES src/sys/i386/i386 genassym.c machdep.c mp_machdep.c pmap.c swtch.s sys_machdep.c vm_machdep.c src/sys/i386/include globaldata.h pcb.h pcb_ext.h ... X-FreeBSD-CVS-Branch: HEAD Precedence: bulk peter 2001/02/22 17:25:02 PST Modified files: sys/conf options.i386 options.pc98 sys/i386/confNOTES sys/i386/i386genassym.c machdep.c mp_machdep.c pmap.c swtch.s sys_machdep.c vm_machdep.c sys/i386/include globaldata.h pcb.h pcb_ext.h sys/i386/svr4svr4_machdep.c sys/pc98/i386machdep.c Log: Activate USER_LDT by default. The new thread libraries are going to depend on this. The linux ABI emulator tries to use it for some linux binaries too. VM86 had a bigger cost than this and it was made default a while ago. Reviewed by: jhb, imp Revision ChangesPath 1.146 +1 -2 src/sys/conf/options.i386 1.117 +1 -2 src/sys/conf/options.pc98 1.891 +1 -8 src/sys/i386/conf/NOTES 1.107 +1 -9 src/sys/i386/i386/genassym.c 1.442 +3 -8 src/sys/i386/i386/machdep.c 1.147 +1 -4 src/sys/i386/i386/mp_machdep.c 1.273 +1 -2 src/sys/i386/i386/pmap.c 1.111 +1 -4 src/sys/i386/i386/swtch.s 1.53 +2 -10 src/sys/i386/i386/sys_machdep.c 1.153 +3 -9 src/sys/i386/i386/vm_machdep.c 1.24 +2 -2 src/sys/i386/include/globaldata.h 1.36 +1 -5 src/sys/i386/include/pcb.h 1.5 +1 -3 src/sys/i386/include/pcb_ext.h 1.17 +4 -3 src/sys/i386/svr4/svr4_machdep.c 1.207 +3 -8 src/sys/pc98/i386/machdep.c To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ** HEADS UP **: bsd.man.mk changes
On Mon, Mar 26, 2001 at 01:28:09PM -0800, Kris Kennaway wrote: On Mon, Mar 26, 2001 at 06:03:38PM +0300, Ruslan Ermilov wrote: Hi! The syntax for declaring manual pages has been changed. The manual pages to be installed can now be listed in a single MAN variable. The old MAN[1-9] syntax is still supported, for backwards compatibility. The plan is to MFC this feature after 4.3 release, and start the deorbit sequence for MAN[1-9] syntax. Developers, please make sure all new Makefiles use the new syntax. I welcome the changes, but don't think the old version should be removed: third party software uses it, and it would not serve any purpose to break them. I'm definitely with Kris on this one; and I know of at least two other people, who are using the bsd.*.mk files (albeit a little modified), in their work. G'luck, Peter -- If wishes were fishes, the antecedent of this conditional would be true. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: status of KSE?
On Fri, Mar 16, 2001 at 12:59:24PM +0800, David Xu wrote: Hello Julian, Friday, March 16, 2001, 12:18:15 PM, you wrote: JE David Xu wrote: I wonder status of KSE, I am dreaming rewrite our application server using kqueue+pthread(KSE), current, we use poll()+pthread because pthread does not work with kqueue at present. -- Best regards, David Xu JE KSE is not into coding yet. JE we have a basic design and have soem documents but JE have been waiting for the SMPng stuff to settle a bit before we JE hit the kernel with a second huge change. JE It will not be ready for a long time. do not assume that it JE will be ready for when you need it becasue it will not. I know KSE is not related to SMP and will run on UP. my primary idea is want to run parellel I/O task in same process with pthread, simply because FreeBSD pthread does not allow me to do multipile I/O tasks at same time on disk file, of course, it is also conflicted with SYSV IPC, so I think of KSE. I don't care about SMP, CPU is enough fast now, I have already seen 1.3G hz CPU, how fast! I think Intel and AMD can very easy to double their CPU clock, hope I can see 3Ghz CPU in next year. I really do think KSE should work before SMP, but it is obvious not. think about Apache 2.0, it is already multi-threaded, FreeBSD pthread will be blocked at disk I/O, it is very bad for Apache 2.0 . I believe Julian's SMP-related comments were referring to the fact that SMP development has rendered the -current kernel somewhat unstable at times (to say the least). KSE-related work would introduce yet another probable path for instabilities, and the developers prefer dealing with one huge monster at a time. There is also the fact that KSE work shall most probably touch many places in the kernel that SMP development also touches - yet another reason to postpone KSE until SMP is kind-of done. G'luck, Peter -- You have, of course, just begun reading the sentence that you have just finished reading. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
dev/acpica/acpi.c - minor patch for cleaner poweroff
Hi,
I think you're the main maintainer of the ACPICA codebase (and yes, I know
that parts of it is imported from Intel). Attached is a trivial patch which
makes for cleaner testing for RB_POWEROFF in acpi_shutdown_final() - I've had
various kernel/userland routines invoke reboot sequences where the howto had
more bits set than RB_POWEROFF, e.g. RB_NOSYNC. With this patch, shutdown -p
works for me :)
Thanks for all the work on ACPICA :)
G'luck,
Peter
PS. Please CC: me in replies as I'm not on -current.
--
If I had finished this sentence,
Index: acpi.c
===
RCS file: /home/ncvs/src/sys/dev/acpica/acpi.c,v
retrieving revision 1.7
diff -u -r1.7 acpi.c
--- acpi.c 2000/12/12 14:20:27 1.7
+++ acpi.c 2000/12/18 14:55:43
@@ -657,7 +657,7 @@
{
ACPI_STATUSstatus;
-if (howto == RB_POWEROFF) {
+if (howto RB_POWEROFF) {
printf("Power system off using ACPI...\n");
if ((status = AcpiSetSystemSleepState(ACPI_STATE_S5)) != AE_OK) {
printf("ACPI power-off failed - %s\n", acpi_strerror(status));
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
logo_saver in VESA 800x600 mode - syscons kbd freeze
Hi, I've decided to finally start playing with -current a day or five ago. One of the first experiences was a funny syscons keyboard freeze when using a custom kernel with 'options VESA' and the logo_saver kernel module. The symptoms: after the saver relinquishes control, the keyboard is kind of frozen; 'kind of', because the controlling keys still work - Alt+Fx switches consoles, Ctrl-PrtScr escapes to DDB, Alt-arrows also switch consoles. However, any 'real' key typed has no effect - nothing appears on the screen and no action is taken - not on the login prompt, not on the shell cmdline, not within an editor. Even Ctrl-Alt-Del is ignored :( The only way to restart the system is by calling restart or panic inside DDB. Attached is my kernel config (derived from GENERIC), and a backtrace of the panic crashdump. More details, including the crashdump and the kernels (booted and debugging) shall be posted shortly on a website - they are currently being uploaded via a slow modem link, and the vmcore is *huge*, even when bzipped :) The webpage index is already there, so are the debug logs and the kernel images, the vmcore shall take a bit longer to arrive. Details at http://mail.orbitel.bg/~roam/crash/logo_vesa.html The *.2.* files are from a -current source tree as of Dec 10, 16:58 EEST. The *.1.* files are from a source tree as of.. mm.. yesterday, I think; however, I do not think many relevant changes have been made to either syscons or the logo_saver source in the meantime. If I'm doing something much wrongly, feel free to beat me up with the heaviest cluestick around :) G'luck, Peter PS. I do not know anything about the syscons/saver interaction; as a matter of fact, i know next to nothing about syscons itself. So things might take a bit of handholding here :) PPS. Please CC: me, as I'm not on -current (or just honor the Mail-Followup-To header ;) -- This sentence contradicts itself - or rather - well, no, actually it doesn't! # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # #http://www.FreeBSD.org/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the NOTES configuration file. If you are # in doubt as to the purpose or necessity of a line, check first in NOTES. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.292 2000/12/08 20:08:18 phk Exp $ machine i386 #cpuI386_CPU #cpuI486_CPU #cpuI586_CPU cpu I686_CPU ident RING-5 maxusers32 #To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" #Default places to look for devices. makeoptions DEBUG=-g3 #Build kernel with gdb(1) debug symbols options MATH_EMULATE#Support for x87 emulation options INET#InterNETworking #optionsINET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options FFS_ROOT#FFS usable as root device [keep this!] options SOFTUPDATES #Enable FFS soft updates support #optionsMFS #Memory Filesystem #optionsMD_ROOT #MD is a potential root device options NFS #Network Filesystem #optionsNFS_ROOT#NFS usable as root device, NFS required options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem #optionsCD9660_ROOT #CD-ROM usable as root, CD9660 required #optionsDEVFS #Device Filesystem options PROCFS #Process filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=15000#Delay (in ms) before probing SCSI options UCONSOLE#Allow users to grab the console options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options P1003_1B#Posix P1003_1B real-time extensions options _KPOSIX_PRIORITY_SCHEDULING options KBD_INSTALL_CDEV# install a CDEV entry in /dev # To make an SMP kernel, the next two are needed #optionsSMP
Re: Fdescfs updates--coming to a devfs near you!
On Thu, Sep 14, 2000 at 01:12:10AM -0700, Julian Elischer wrote: I've never thought of a use for fdescfs... Well.. just a trivial example - imagine a program which takes a filename as an argument; imagine yourself trying to pipe something into it - passing /dev/fd/0 as a filename to process would do the trick. G'luck, Peter -- .sith ekil ti gnidaer eb d'uoy ,werbeH ni erew ecnetnes siht fI To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
