Re: symlink question
On Sunday, 13th June 1999, Chuck Youse wrote: Forgive my ignorance, but what exactly is meant by a variant link, and what might one be used for? Abused, not used. A number of incredibly dodgy things can be done with symlinks that point here at one moment and there at another moment based on the current value of some environment variable, or other hidden system variable. I cough up a lung every time this topic is raised. Variant symlinks have caused me grief (Pyramid OSx) and never joy. I hope it fails yet again to appear in FreeBSD. Just think of the new security holes for a start. Stephen. Oh, namei! What have they done to thee? -- John Mackin, on seeing Apollo's variant symlinks. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: symlink question
symlinks have caused me grief (Pyramid OSx) and never joy. I hope it fails yet again to appear in FreeBSD. Just think of the new security holes for a start. Name one, please. You can currently point a symlink anyplace you like; whether the user has permission to *read* or execute the target of the link, however, is where the genuine system administration takes over. How the actual value is derived shouldn't make that much difference. :) - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: symlink question
On Mon, 14 Jun 1999, Jordan K. Hubbard wrote:
symlinks have caused me grief (Pyramid OSx) and never joy. I hope it fails
yet again to appear in FreeBSD. Just think of the new security holes for a
start.
Name one, please. You can currently point a symlink anyplace you
like; whether the user has permission to *read* or execute the target
of the link, however, is where the genuine system administration takes
over. How the actual value is derived shouldn't make that much
difference. :)
First try: Suppose foo depends on /usr/local/etc/foo.conf.
/usr/local/etc is a link to /usr/local/${ARCH}/etc. User does
export $ARCH=../../home/user, so /usr/local/etc/foo.conf is now in
their home directory. Depending on how poorly written foo is
written, it may be possible for the user to get foo to do things
it wouldn't normally. There a bunch of these sorts of things
lurking here. Clearly, navigation up the tree can't be allowed,
at least for processes operating with increased privs. There are
probably some other path subversion issues, or potential issues,
lurking in this. This is not to say this isn't a good idea. I
can think of serveral uses that would make my life easier.
David Scheidt
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: symlink question
On Monday, 14th June 1999, Jordan K. Hubbard wrote:
symlinks have caused me grief (Pyramid OSx) and never joy. I hope it fails
yet again to appear in FreeBSD. Just think of the new security holes for a
start.
Name one, please. You can currently point a symlink anyplace you
like; whether the user has permission to *read* or execute the target
of the link, however, is where the genuine system administration takes
over. How the actual value is derived shouldn't make that much
difference. :)
Yes, symlinks caused (still cause?) havoc when introduced! And with
variant symlinks, you lose the ability to statically verify where things
go. A safe symlink (right now) becomes a dangerous one not when the file
system is changed, but when some transient variable changes. I don't like
that at all. I don't want to have to think through all the consequences.
You might consider this sort of shifting of the goal posts (the subtle change
to the behaviour of absolutely every program) as a minor inconvenience, and
acceptable in order to gain the benefits of variant links. I don't think
that way, partially because I don't see them as a real benefit, with more
wow effect than real utility. Everyone points out the /${ARCH}/bin
use, but that can be done in other ways (eg just set PATH) that don't
cost much (admin time or cpu time).
Stephen.
PS On second thoughts, I think Mackin was pointing and exclaiming at a
Tektronix workstation. Did they have variant links?
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
ZD labs test update
Straight back from Usenix, I've returned to ZD labs to continue with the benchmarking attempt we started the week before last. Just to remind everyone, this is the standard Samba-and-Apache runaround with the addition of Zeus to the mix in order to get a feel for its relative performance. The goal here is to add a FreeBSD column to the tests published in PC Week a little while back. The system configuration is as follows; - Compaq Proliant 6100 (an engineering sample) with 4x500MHz PII Xeons and 2GB of RAM. - One Seagate Cheetah for the system disk, on an Adaptec 2940U2W. - Seven Seagate Cheetahs for the data volume, managed by an Infortrend 3201U2, organised as a single RAID5 volume (this is a test requirement) and hung off another 2940U2W. - Four Intel EtherExpress Pro/100's. The RAID controller was kindly loaned by Telenet Systems, the rest of the equipment is provided by ZD labs themselves. Today's progress was greatly aided by Peter Wemm, who managed to miss his flight out last night, and was thus dragged along. This gave us a fighting chance against the Compaq system, which fought us at almost every turn. I'm sure these systems are wonderful servers, but they've got to be towards the more painful end of the spectrum when it comes to setting them up. We'd previously encountered problems with the Infortrend controller not at all liking the other disks we'd tried to talk to; a collection of Cheetahs with IBM and Compaq firmware simply wouldn't work. This time we had better luck with real Seagate firmware, and the array performance wasn't too shabby, giving us ~8MB/sec write performance and ~16MB/sec read performance using the dd-stone benchmark. Following established lore, it was necessary to use the secret Ctrl-A hotkey to enable Advanced mode in the Compaq setup program so that the MP table could be set to 'Full Table' mode, as well as rearrange interrupts so that nothing useful was given IRQ 9. This latter was necessary as otherwise the system was presented with around 100,000 interrupts per second, from an unknown source. This consumed about 6% CPU (according to systat) in SMP mode, and caused the peripheral with that IRQ to fail miserably. A few other minor tweaks were performed (upping the buffer cache sizing by setting NBUF to 32,000) and a set of kernels built for UP, 2-way and 4-way SMP. Thus, the ground is prepared for us to begin testing with Samba tomorrow. More news as it comes... -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msm...@freebsd.org \\-- Joseph Merrick \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: coarse vs fine-grained locking in SMP systems
m...@servo.ccr.org (Mike O'Dell) writes: very fine-grain-locked systems often display convoying and are prone to priority inversion problems. coarse-grained Priority inversion problems are design flaws. Depending on the type of locks, they may not even be possible. Spin locks held for short periods of time (typical for very fine-grained systems) can't cause priority inversion because the process holding the lock can't block. we published the best Unix SMP paper I've ever seen in Computing Systems - from the Amdahl guys who did an SMP version of the kernel by very clever hacks on SPLx() macros to make them spin locks and a bit of other clever trickery on the source. they could take a stock An approach like that can't possibly be sufficient if code has been written with the assumption that only interrupt-like events or blocking calls can change things from under it. There is quite a bit of code in FreeBSD that relies on this. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: NFSv3 fixes...
:Who, me? Open a can of worms? ;) Heh! : We are going to have to instrument the code - basically means NULLing : out ni_vp and any local vnode pointer when the vnode in question is : released so we can keep track of it and putting KASSERT()s in strategic : places. nfs_namei() in nfs/nfs_subs.c and just about all the subroutines : defined in nfs/nfs_serv.c. : :That was along the lines of my thoughts too... it became painfully obvious :that this sort of bug could be (and probably is) everywhere in the nfs :server code. I will be happy to follow your lead on this (honored one :may say). I am hoping to have some time to deal with this tonight, but I did :just get my CD-RW drive. We should probably take the time to document the :code some more while we are at it... simple things like commenting what :braces go to what would have greatly eased my trace through the code :) : :-- :David Cross :The source will be with you, always. Well, I looked at the code some more. The bugs in nfs_namei() are easy to fix. Unfortunately, I found some truely horrendous bugs in nfs_serv.c. Sometimes 'dirp' is not properly released, there is a double-free of nd.ni_cnd.cn_pnbuf in one place, sometimes nd.ni_startdir is not always released. This is on top of the bugs you found with nd.ni_vp and nd.ni_dvp not always being properly released! The nfs_serv.c module is going to have to be seriously cleaned up, which basically means a rewrite of the more complex procedures. I think I can do it fairly easily, and comment it along the way. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: symlink question
dsche...@enteract.com (David Scheidt) writes:
First try: Suppose foo depends on /usr/local/etc/foo.conf.
/usr/local/etc is a link to /usr/local/${ARCH}/etc. User does
export $ARCH=../../home/user, so /usr/local/etc/foo.conf is now in
their home directory. Depending on how poorly written foo is
Eww, I don't like the idea of using environment variables this way.
The kernel shouldn't rely on them, they are a userland thing except
during execve. Environment variables aren't even visible to the
kernel in the process that sets them.
Variant symlinks don't need to be controlled through environment
variables. If there is a specific use in mind for variant symlinks,
the mechanism for configuring them should be chosen with consideration
for that. (Even if variant symlinks could be environment variables,
there should be ones that are based on some hard-wired info and
system-wide variant symlinks should only use environment variables
when user-modifiability is specifically desirable. Your example is
obviously a case of improper use.)
If there is no specific use in mind for variant symlinks, other than
to have fun magic thingies around to play with that *can* be used for
such-and-such, then implementing them is not a particularly good idea.
For example, Lites had variant symlinks with keywords that were
internally resolved to the architecture/system name or the name of the
system being emulated.
For Lites, this was much better than something equivalent to FreeBSD's
/compat hacks, because emulated systems were equal, and the root
partition could be shared with the real system. For FreeBSD, the
current approach is probably better, because emulated systems are
optional exceptions.
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: oops, here's the patch
dil...@apollo.backplane.com (Matthew Dillon) writes:
However, if the inside of the first conditional generates an error, the vp
may be vput twice. What I recommend is this for the last bit:
That can't happen (the attributes are straight from VATTR_NULL along
that path) - if it could, the file could also be truncated...
if (vap-va_size != -1) {
...
if (error) {
vput(vp);
vp = NULL; my addition
}
}
if (eexistdebug vp) also check vp != NULL
vput(vp);
It would be good if someone else could look over this routine and
double-check David's find and his solution with my modification. Have
we handled all the cases?
Yes, for that code path.
Here's a simpler virtual unified diff that does the same thing as
David's patch. (You don't need an 'eexistdebug' variable.)
if (vap-va_size != -1) {
...
- if (error)
- vput(vp);
}
+ if (error)
+ vput(vp);
You can add a check for 'error == 0' in addition to
'vap-va_size != -1' but that shouldn't have any effect.
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: IR Remote for AverMedia and FlyVideo
On Thu, Jun 10, 1999 at 02:16:57PM +0100, Roger Hardiman wrote: Hi, Several people have asked my recently about supporting the AverMedia remote control and the FlyVideo Remote Control units for their Bt848/Bt878 TV cards. Well, I finally got a reply from AverMedia and after checking on the Linux Infra Red Controller (LIRC) web site, I found the source and specs for the AverMedia and FlyVideo IR modules. I do not have AverMedia or Flyvideo hardware, so I'm not going to look into it, but if owner/hackers of these cards want to knock something up for the Bt848 driver, I'll gladly add it in along side the Hauppauge IR support we already have. Hi Roger, I've got a phototransistor plugged into my DTR line on the serial port. Is there any working software for FreeBSD for utilising this? (I want to never lose a remote control again!) Joe -- Josef KarthauserFreeBSD: How many times have you booted today? Technical Manager Viagra for your server (http://www.uk.freebsd.org) Pavilion Internet plc. [...@pavilion.net, j...@uk.freebsd.org, j...@tao.org.uk] To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: symlink question
symlinks have caused me grief (Pyramid OSx) and never joy. I hope it fails yet again to appear in FreeBSD. Just think of the new security holes for a start. Name one, please. You can currently point a symlink anyplace you like; whether the user has permission to *read* or execute the target of the link, however, is where the genuine system administration takes over. How the actual value is derived shouldn't make that much difference. :) - Jordan My biggest problem with variant symlinks (which I've preached on before) is the following scenario: o) User A runs program P which takes advantage of a variant symlink in some fashion (either in finding P or finding some data P needs, etc...) o) User B runs program P which fails miserably. o) The sysadmin notes that the machines are the same, the symlinks are the same... then has to track down user B, and has to determine what variant symlinks P has been (perhaps even unaware to the designers of P) using and then has see what in user B's environment is causing this problem. Muliply B by several hundred... We would have problems like that on our Apollos; learning the hard way to avoid variant symlinks... just to ensure the environment was as expected.You don't have these same questions with plain symlinks. And, if the symlink changes, it's quite easy to see that it changed... So - I'd say that variant symlinks are like many other things, it's really easy to shoot yourself in the foot.. In my opinion variant symlinks make it too easy. Sometimes nifty things don't need to be done. I'd suggest that if they were implemented in FreeBSD - we leave the support 'off' by default, with a sysctl variable to enable them. When a user posts that his XXX/YYY/ZZZ directory has gone away we can ask, are variant symlinks turned on? and have a good first guess as to the culprit. Just my thoughts - Dave Rivers - To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ZD labs test update
--- Mike Smith m...@smith.net.au wrote: We'd previously encountered problems with the Infortrend controller not at all liking the other disks we'd tried to talk to; a collection of Cheetahs with IBM and Compaq firmware simply wouldn't work. This time we had better luck with real Seagate firmware, and the array performance wasn't too shabby, giving us ~8MB/sec write performance and ~16MB/sec read performance using the dd-stone benchmark. Isn't 16MB/s quite bad for this kind of system? === Regards, Tommy Hallgren Briljantg. 31, SE-421 49, Göteborg Tel.: 031 - 770 5232 (Work: Telia Prosoft) Tel.: 0709 - 312 404 (GSM) Tel.: 031 - 47 65 28 (Home) _ DO YOU YAHOO!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
RE: ZD labs test update
-Original Message- From: Tommy Hallgren [SMTP:thallg...@yahoo.com] Sent: Tuesday, June 15, 1999 1:23 PM To: Mike Smith; hack...@freebsd.org Subject: Re: ZD labs test update Isn't 16MB/s quite bad for this kind of system? [ML] Figuring in the SCSI overhead, 16 MBps, where MB is 2^20B, is pretty much the limit of the fast-wide or ultra-narrow SCSI. So, it depends on the RAID and the SCSI chain. /Marino To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Inactive vs. free Memory
Just for my infomation. What is the difference between Inactive and Free memory. Right now top says I have 157M Inact and 3260K Free. Jim -- James E. HousleyPGP: 1024/03983B4D System Supply, Inc. 2C 3F 3A 0D A8 D8 C3 13 Pager: page...@notepage.com 7C F0 B5 BF 27 8B 92 FE The box said 'Requires Windows 95, NT, or better,' so I installed FreeBSD To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
dumpon
I've yesterday tried to get kernel dumps to work and failed (and instead just fixed the bug I was looking for :-). The manpage for dumpon seems to be out of date. Adding dump on wd0s2b to the KERNEL config file, gives me a syntax error in that line. And adding the dumpdev to rc.conf is too late as I want the machine to go pop before the filesystems are mounted RW. Any pointers on how I can switch on dumping to the swap partition (/dev/wd0s2b), to be enabled at boot time? Nick -- ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: umapfs...
David E. Cross cro...@cs.rpi.edu writes: I have been looking at the code for UMAPfs... I am trying to understand conceptually why it is so unstable... You're looking in the wrong place. It's unstable because of infrastructure problems which require fairly substantial amounts of work to correct. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: umapfs...
I have been looking at the code for UMAPfs... I am trying to understand
conceptually why it is so unstable...
You're looking in the wrong place. It's unstable because of
infrastructure problems which require fairly substantial amounts of
work to correct.
DES
I guess that is what I am asking... What is different between the following:
int foo(void){
return 0;
}
and
int foo_prime(void) {
return foo();
}
That is my interpretation of the code. It would *seem* to just pass the
call off to the next FS layer as if the VFS system of the kernel had done it
directly Conceptually I must be missing something.
--
David Cross | email: cro...@cs.rpi.edu
Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself. | WinNT:Linux::Linux:FreeBSD
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: umapfs...
David E. Cross cro...@cs.rpi.edu writes: That is my interpretation of the code. It would *seem* to just pass the call off to the next FS layer as if the VFS system of the kernel had done it directly Conceptually I must be missing something. Umm, umapfs rewrites the owner/group of vnodes if I'm not mistaken. That's the whole point with it. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
[Call for review] init(8): new feature
Hi, hackers!
While the -core is busy to review/approve this patch,
I would like to know your opinion. What do you think
of it?
Thanks,
--
Ruslan Ermilov Sysadmin and DBA of the
r...@ucb.crimea.ua United Commercial Bank,
r...@freebsd.orgFreeBSD committer,
+380.652.247.647Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
---BeginMessage---
Hi!
We have a lot of PRs (5451, 9066, 10035) complaining the lack
of running /etc/rc.shutdown from shutdown(8)/reboot(8).
In fact, there are two ways to cleanly (with /etc/rc.shutdown)
reboot the system:
- send init(8) SIGINT signal;
- run shutdown(8) without ``-r'' and ``-h'' switches, so it
will send init(8) SIGINT signal.
On the other hand, there is no easy (single-step) way to run
/etc/rc.shutdown and then halt plus optionally power-off the
system.
The patch below (mostly from PR#5451) removes this limitation
by adding two new features to init(8):
- when init(8) receives SIGUSR1, it will act like in SIGINT
case, but will call reboot(RB_HALT);
- when init(8) receives SIGUSR2, it will act like in SIGINT
case, but will call reboot(RB_HALT|RB_POWEROFF).
Also, when compiled with -DCOMPAT_SYSV_INIT, it is now possible
to emulate SysV's init(8) behaviour.
I have tested it on my 3.2-STABLE, and it works like a charm.
Very handy!!!
Could you please review it?
Thanks,
--
Ruslan Ermilov Sysadmin and DBA of the
r...@ucb.crimea.ua United Commercial Bank
+380.652.247.647Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
Index: Makefile
===
RCS file: /usr/FreeBSD-CVS/src/sbin/init/Makefile,v
retrieving revision 1.15
diff -u -r1.15 Makefile
--- Makefile1998/01/20 10:39:56 1.15
+++ Makefile1999/06/11 20:14:19
@@ -6,6 +6,7 @@
BINMODE=500
INSTALLFLAGS=-fschg
CFLAGS+=-DDEBUGSHELL -DSECURE -DLOGIN_CAP
+CFLAGS+=-DCOMPAT_SYSV_INIT
.if exists(${.CURDIR}/../../secure) !defined(NOCRYPT) !defined(NOSECURE)
DISTRIBUTION=des
Index: init.c
===
RCS file: /usr/FreeBSD-CVS/src/sbin/init/init.c,v
retrieving revision 1.31
diff -u -r1.31 init.c
--- init.c 1998/07/22 05:45:11 1.31
+++ init.c 1999/06/11 20:28:59
@@ -132,6 +132,7 @@
#define TRUE 1
int Reboot = FALSE;
+int howto = RB_AUTOBOOT;
int devfs;
@@ -203,9 +204,44 @@
errx(1, %s, strerror(EPERM));
/* System V users like to reexec init. */
- if (getpid() != 1)
- errx(1, already running);
-
+ if (getpid() != 1) {
+#ifdef COMPAT_SYSV_INIT
+ /* So give them what they want */
+ if (argc 1) {
+ if (strlen(argv[1]) == 1) {
+ register char state = *argv[1];
+ register int sig;
+
+ switch (state) {
+ case '0': /* halt + poweroff */
+ sig = SIGUSR2;
+ break;
+ case '1': /* single user */
+ case 's':
+ sig = SIGTERM;
+ break;
+ case '6': /* reboot */
+ sig = SIGINT;
+ break;
+ case 'q': /* re-read /etc/ttys */
+ sig = SIGHUP;
+ break;
+ case 'c': /* block further logins */
+ sig = SIGTSTP;
+ break;
+ default:
+ goto usage;
+ }
+ kill(1, sig);
+ _exit(0);
+ } else
+usage:
+ errx(1, invalid level ``%s''\n
+ usage: init [016cqs], argv[1]);
+ } else
+#endif
+ errx(1, already running);
+ }
/*
* Note that this does NOT open a file...
* Does 'init' deserve its own facility number?
@@ -259,11 +295,13 @@
handle(badsys, SIGSYS, 0);
handle(disaster, SIGABRT, SIGFPE, SIGILL, SIGSEGV,
SIGBUS, SIGXCPU, SIGXFSZ, 0);
- handle(transition_handler, SIGHUP, SIGINT, SIGTERM, SIGTSTP, 0);
+ handle(transition_handler, SIGHUP, SIGINT, SIGTERM, SIGTSTP,
+
Re: Inactive vs. free Memory
James E. Housley j...@thehousleys.net writes: Just for my infomation. What is the difference between Inactive and Free memory. Right now top says I have 157M Inact and 3260K Free. Inactive means the page contains valid data belonging to some file, but is not mapped into any address space. Free means, the page doesn't contain valid data. -Arun To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: [Call for review] init(8): new feature
While we're on the init topic, is there any strong feeling here about BSD /etc/rc* scripts Vs SysV ? The nice thing about SysV initscripts is the ability to start and stop any service that I like. -Arun To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: [Call for review] init(8): new feature
On Tue, 15 Jun 1999, Ruslan Ermilov wrote: While the -core is busy to review/approve this patch, I would like to know your opinion. What do you think of it? The sysv init should probably be off by default. - bill fumerola - bi...@chc-chimes.com - BF1560 - computer horizons corp - - ph:(800) 252-2421 - bfume...@computerhorizons.com - bi...@freebsd.org - To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Inactive vs. free Memory
On Tue, Jun 15, 1999 at 08:54:23AM -0700, Arun Sharma wrote: James E. Housley j...@thehousleys.net writes: Just for my infomation. What is the difference between Inactive and Free memory. Right now top says I have 157M Inact and 3260K Free. Inactive means the page contains valid data belonging to some file, but is not mapped into any address space. Free means, the page doesn't contain valid data. Thanks Arun, This has been bugging us for ages :) At last it's clear yippee Joe -- Josef KarthauserFreeBSD: How many times have you booted today? Technical Manager Viagra for your server (http://www.uk.freebsd.org) Pavilion Internet plc. [...@pavilion.net, j...@uk.freebsd.org, j...@tao.org.uk] To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: [Call for review] init(8): new feature
On Tue, Jun 15, 1999 at 07:51:54AM -0400, Bill Fumerola wrote: On Tue, 15 Jun 1999, Ruslan Ermilov wrote: While the -core is busy to review/approve this patch, I would like to know your opinion. What do you think of it? The sysv init should probably be off by default. Sure, I turned it on only for test purposes, in case someone wants to try it out. -- Ruslan Ermilov Sysadmin and DBA of the r...@ucb.crimea.ua United Commercial Bank, r...@freebsd.orgFreeBSD committer, +380.652.247.647Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
NFS hangs on reads?
Umm, recently I've noticed for both 3.2 4.0 that NFS seems to get wedged on a directory that is mounted from a Solaris 2.6 (unpatched) server- but this seems to only happen if the local mount point is a directory just off of root. The scenario is, e.g.: bird:/export/home on /home bird:/space5/freebsd on /freebsd bird:/space5/freebsd/distfiles on /usr/ports/distfiles bird:/src/freebsd-current/src on /usr/src a 'ls' of /home hangs. Then a 'ls' of /home/mjacob and /usr/src hangs... the ps commands have: 31154 31830 31802 0 -18 0 360 212 nfsngt D+p10:00.00 (ls) 31154 31869 1 0 -18 0 360 212 nfsngt D p2- 0:00.00 (ls) Sorry- this is a bit vague- I'll track it down further if this isn't already a known problem I'll track this more carefully. I first saw this with 3.2-stable, but it also is happening with -current as of today. A quick perusal of the nfs_node code doesn't suggest much to me. I should point out that both systems are 2xPPro SMP systems. -matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Inactive vs. free Memory
Arun Sharma said: James E. Housley j...@thehousleys.net writes: Just for my infomation. What is the difference between Inactive and Free memory. Right now top says I have 157M Inact and 3260K Free. Inactive means the page contains valid data belonging to some file, but is not mapped into any address space. Free means, the page doesn't contain valid data. Trying to be helpful to follow up with more detail, but slightly inprecise due to the fact that there are still some generalizations: Active pages have been recently mapped into a process by the kernel, most often by virtue of a page fault. Sometimes pages are activated, but not initially mapped, and that is a policy decision. Inactive pages might or might not be mapped into a process recently, but those pages have likely been bumped from the Active list by the pageout daemon. Sometimes the system will initially inactivate a page instead of activating it for policy reasons though. Cache pages are not mapped into a process, but are left around for reuse with intact data. Cache pages are VM cached, but a slightly confusing issue is that buffer cache pages are actually wired. Cache pages are in the netherworld of being free and not-free, and can be used as BOTH empty or cache data. Free pages have no data, and might or might not be prezeroed. Wired pages are often directly used by the kernel, and are not available for involuntary reuse by the actions of the pageout daemon. One of the improvements of FreeBSD VM over the old original code is that it has an in-between form of free pages called cache pages, that are available for immediate reuse both as empty pages or containing their previous contents. This allows for policy mistakes to be buffered further than the LRU-K type algorithm used by the pageout daemon. Adding the cache queue made a significant improvement, over and above the LRU-K style scheme. (Note the FreeBSD implementation of LRU-K is particularly efficient.) -- John | Never try to teach a pig to sing, dy...@iquest.net | it makes one look stupid jdy...@nc.com | and it irritates the pig. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
followup to mysefl: Re: NFS hangs on reads?
Closer examination shows the possible problem:
Rev 1.29 added:
/*
* Insert the nfsnode in the hash queue for its new file handle
*/
for (np2 = nhpp-lh_first; np2 != 0; np2 = np2-n_hash.le_next) {
if (mntp != NFSTOV(np)-v_mount || np2-n_fhsize != fhsize ||
bcmp((caddr_t)fhp, (caddr_t)np2-n_fhp, fhsize))
continue;
vrele(vp);
goto retry;
}
Peter- you brought this over from FreeBSD... what's up?
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
D'oh!
for (np2 = nhpp-lh_first; np2 != 0; np2 = np2-n_hash.le_next) {
if (mntp != NFSTOV(np)-v_mount || np2-n_fhsize != fhsize ||
bcmp((caddr_t)fhp, (caddr_t)np2-n_fhp, fhsize))
continue;
vrele(vp);
goto retry;
}
Peter- you brought this over from FreeBSD... what's up?
OpenBSD!
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: D'oh!
: for (np2 = nhpp-lh_first; np2 != 0; np2 = np2-n_hash.le_next) {
: if (mntp != NFSTOV(np)-v_mount || np2-n_fhsize != fhsize ||
: bcmp((caddr_t)fhp, (caddr_t)np2-n_fhp, fhsize))
: continue;
: vrele(vp);
: goto retry;
: }
:
:
: Peter- you brought this over from FreeBSD... what's up?
:OpenBSD!
:
The problem is that peter is not releasing the nfs_node_hash_lock
when he goes to retry, creating a deadlock with himself.
Peter, looks like a quick fix commit to me, I'd say just go ahead
and do it.
Heh, I just realized how funny that first statement was :-)
-Matt
Matthew Dillon
dil...@backplane.com
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
PCCARD boot.flp for -current (reviewer wanted)
In article 10710.928404...@peewee j...@zippy.cdrom.com writes: 1. Put pccardd on the mfsroot floppy and add a few things to sysinstall (this may already be done by his patches, I haven't had time to check) which enable its use during installation. I've ported PC-card boot.flp to -current. Source patch can be found at http://wing-yee.ntc.keio.ac.jp/hosokawa/pccard-flp/current-diff-19990616.tar.gz and, compiled binaries (boot.flp, kern.flp, and mfsroot.flp) at http://wing-yee.ntc.keio.ac.jp/hosokawa/pccard-flp/current-binaries-19990616.tar.gz With this patch, make PCCARD=YES boot.flp produces PC-card boot.flp and make boot.flp produces normal boot.flp. To make them both automatically, more patches are required, but I think they can be committed later. Please review this patch. I want to commit these patches to -current and -stable. If there are no objection, I'll commit them. -- HOSOKAWA, Tatsumi Assistant Manager Information Technology Center, Keio University hosok...@itc.keio.ac.jp To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: D'oh!
: The problem is that peter is not releasing the nfs_node_hash_lock when he goes to retry, creating a deadlock with himself. Peter, looks like a quick fix commit to me, I'd say just go ahead and do it. Heh, I just realized how funny that first statement was :-) Yup, that's my take too waking up any waiters to re-contend seemed correct to do too Index: nfs_node.c === RCS file: /home/ncvs/src/sys/nfs/nfs_node.c,v retrieving revision 1.29 diff -c -r1.29 nfs_node.c *** nfs_node.c 1999/06/05 05:26:36 1.29 --- nfs_node.c 1999/06/15 17:19:49 *** *** 167,172 --- 167,175 bcmp((caddr_t)fhp, (caddr_t)np2-n_fhp, fhsize)) continue; vrele(vp); + if (nfs_node_hash_lock 0) + wakeup(nfs_node_hash_lock); + nfs_node_hash_lock = 0; goto retry; } LIST_INSERT_HEAD(nhpp, np, n_hash); If peter doesn't respond by this afternoon, I'll commit it. I've tried it on -current so far. -matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: D'oh!
: : Heh, I just realized how funny that first statement was :-) : : :Yup, that's my take too waking up any waiters to re-contend seemed :correct to do too :... : :If peter doesn't respond by this afternoon, I'll commit it. I've tried it :on -current so far. Sounds good to me! If someone on -hackers has easy access to the OpenBSD source, it would be nice if he could check whether the OpenBSD code has the same problem and notify the OpenBSD folks if it does. -Matt Matthew Dillon dil...@backplane.com :Index: nfs_node.c :... : bcmp((caddr_t)fhp, (caddr_t)np2-n_fhp, fhsize)) : continue; : vrele(vp); :+ if (nfs_node_hash_lock 0) :+ wakeup(nfs_node_hash_lock); :+ nfs_node_hash_lock = 0; : goto retry; : } : :-matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: D'oh!
: : Heh, I just realized how funny that first statement was :-) : : :Yup, that's my take too waking up any waiters to re-contend seemed :correct to do too :... : :If peter doesn't respond by this afternoon, I'll commit it. I've tried it :on -current so far. Sounds good to me! If someone on -hackers has easy access to the OpenBSD source, it would be nice if he could check whether the OpenBSD code has the same problem and notify the OpenBSD folks if it does. Good point. I'm a committer there too, so I'll check it and let them know... thx... To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: apmd for FreeBSD
Thanks a lot for your testing. I'm preparing -current NotePC for testing this. imp I've applied the patches to my -current system. I had to apply two by imp hand, and then it just compiled and appeared to work with no ill imp effects on my desktop. It should :) I heard that 3.2-RELEASE kernel patch can be applied to -STABLE (even 2.2-STABLE) with no rejects because there are few differences between them. imp P.S. I've put my diffs vs -current at imphttp://www.freebsd.org/~imp/apmd-sys-current.diff.gz Thanks. Give my kind regards. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
inetd+libwrap and wrapping UDP services
Hi folks, The patches on PR 12097 that deal with fixing inetd's handling of tcp_wrapper support do _not_ enable wrapping of UDP services. David Malone and I are busy working on a patch for doing so, but I have a question that I probably should have asked when we started. Is there any point in wrapping UDP services (identified as dgram udp services in inetd.conf)? Since they're all single-threaded, using the wait option, any successful connection opens up a rolling period during which any further connections will not be wrapped (hence the word rolling). So what's the point? Obviously, if there's a real need for wrapping UDP services, we'll carry on grafting. Thanks, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: inetd+libwrap and wrapping UDP services
On Tue, Jun 15, 1999 at 08:01:55PM +0200, Sheldon Hearn wrote: Hi folks, The patches on PR 12097 that deal with fixing inetd's handling of tcp_wrapper support do _not_ enable wrapping of UDP services. David Malone and I are busy working on a patch for doing so, but I have a question that I probably should have asked when we started. Is there any point in wrapping UDP services (identified as dgram udp services in inetd.conf)? Since they're all single-threaded, using the wait option, any successful connection opens up a rolling period during which any further connections will not be wrapped (hence the word rolling). And when you fix that, the wrapper stuff gets invoked for every packet... -Guido To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: inetd+libwrap and wrapping UDP services
On Tue, 15 Jun 1999 20:05:10 +0200, Guido van Rooij wrote: And when you fix that, the wrapper stuff gets invoked for every packet... Even worse than I anticipated. :-) So then we just note in the manpage that only TCP-based services are wrapped? Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: D'oh!
On Tue, Jun 15, 1999 at 10:37:18AM -0700, Matthew Dillon wrote:
Sounds good to me! If someone on -hackers has easy access to the OpenBSD
source, it would be nice if he could check whether the OpenBSD code
has the same problem and notify the OpenBSD folks if it does.
they dont seem to have the nfs_node_hash_lock at all.
Our code in nfs_nget():
loop:
for (np = nhpp-lh_first; np != 0; np = np-n_hash.le_next) {
if (mntp != NFSTOV(np)-v_mount || np-n_fhsize != fhsize ||
bcmp((caddr_t)fhp, (caddr_t)np-n_fhp, fhsize))
continue;
vp = NFSTOV(np);
if (vget(vp, 1))
goto loop;
*npp = np;
return(0);
}
/*
* Obtain a lock to prevent a race condition if the getnewvnode()
* or MALLOC() below happens to block.
*/
if (nfs_node_hash_lock) {
while (nfs_node_hash_lock) {
nfs_node_hash_lock = -1;
tsleep(nfs_node_hash_lock, PVM, nfsngt, 0);
}
nfs_node_hash_lock = 1;
/*
* Do the MALLOC before the getnewvnode since doing so afterward
* might cause a bogus v_data pointer to get dereferenced
* elsewhere if MALLOC should block.
*/
MALLOC(np, struct nfsnode *, sizeof *np, M_NFSNODE, M_WAITOK);
error = getnewvnode(VT_NFS, mntp, nfsv2_vnodeop_p, nvp);
Their code:
loop:
for (np = nhpp-lh_first; np != 0; np = np-n_hash.le_next) {
if (mntp != NFSTOV(np)-v_mount || np-n_fhsize != fhsize ||
bcmp((caddr_t)fhp, (caddr_t)np-n_fhp, fhsize))
continue;
vp = NFSTOV(np);
if (vget(vp, LK_EXCLUSIVE, p))
goto loop;
*npp = np;
return(0);
}
error = getnewvnode(VT_NFS, mntp, nfsv2_vnodeop_p, nvp);
if (error) {
*npp = 0;
return (error);
}
vp = nvp;
MALLOC(np, struct nfsnode *, sizeof *np, M_NFSNODE, M_WAITOK);
I have not checked if they have fixed this otherwise though.
-Guido
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: inetd+libwrap and wrapping UDP services
On Tue, 15 Jun 1999 20:07:02 +0200, Sheldon Hearn wrote: So then we just note in the manpage that only TCP-based services are wrapped? And don't even _think_ about telling me that the phrase Support is provided for TCP Wrappers doesn't say anything about UDP. ;-) Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
PATCH for NE2000 driver--if_ed.c
patch adds support for the Linksys 10/100 PCMCIA card
if you have a NE2000 type card which is supported by if_ed.c, please
apply this patch and provide feedback. it work wonderfully for me,
but i have only two cards that use this driver.there are a wide
variety of cards that use the if_ed.c driver. i want to make sure of
the change before committing it.
*** /sys/i386/isa/if_ed.c.orig Tue Jan 2 05:33:53 1990
--- /sys/i386/isa/if_ed.c Sun Jun 6 06:59:40 1999
***
*** 193,198
--- 193,200
static u_long ds_crc __P((u_char *ep));
+ static inted_get_Linksys __P((struct ed_softc *));
+
#if (NCARD 0) || (NPNP 0)
#include sys/kernel.h
#endif
***
*** 410,415
--- 412,435
return (1);
}
+ static int
+ ed_get_Linksys(sc)
+ struct ed_softc *sc;
+ {
+ u_char sum;
+ int i;
+
+ for (sum = 0, i = 0x14; i 0x1c; i++)
+ sum += inb(sc-nic_addr +i);
+ if (sum != 0xff)
+ return (0);
+ for (i = 0; i ETHER_ADDR_LEN; i++) {
+ sc-arpcom.ac_enaddr[i] = inb(sc-nic_addr + 0x14 + i);
+ printf(%02x., sc-arpcom.ac_enaddr[i]);
+ }
+ return (1);
+ }
+
/*
* Probe and vendor-specific initialization routine for SMC/WD80x3 boards
*/
***
*** 1072,1077
--- 1092,1098
u_char romdata[16], tmp;
static char test_pattern[32] = THIS is A memory TEST pattern;
chartest_buffer[32];
+ int linksys = 0;
sc-asic_addr = port + ED_NOVELL_ASIC_OFFSET;
sc-nic_addr = port + ED_NOVELL_NIC_OFFSET;
***
*** 1141,1147
ed_pio_writemem(sc, test_pattern, 8192, sizeof(test_pattern));
ed_pio_readmem(sc, 8192, test_buffer, sizeof(test_pattern));
! if (bcmp(test_pattern, test_buffer, sizeof(test_pattern))) {
/* not an NE1000 - try NE2000 */
outb(sc-nic_addr + ED_P0_DCR, ED_DCR_WTS | ED_DCR_FT1 |
ED_DCR_LS);
--- 1162,1174
ed_pio_writemem(sc, test_pattern, 8192, sizeof(test_pattern));
ed_pio_readmem(sc, 8192, test_buffer, sizeof(test_pattern));
! linksys = ed_get_Linksys(sc);
! if (linksys) {
! outb(sc-nic_addr + ED_P0_DCR, ED_DCR_WTS | ED_DCR_FT1 |
ED_DCR_LS);
! sc-isa16bit = 1;
! sc-type = ED_TYPE_NE2000;
! sc-type_str = Linksys;
! } else if (bcmp(test_pattern, test_buffer, sizeof(test_pattern))) {
/* not an NE1000 - try NE2000 */
outb(sc-nic_addr + ED_P0_DCR, ED_DCR_WTS | ED_DCR_FT1 |
ED_DCR_LS);
***
*** 1251,1269
* Use one xmit buffer if 16k, two buffers otherwise (if not told
* otherwise).
*/
! if ((memsize 16384) || (flags ED_FLAGS_NO_MULTI_BUFFERING))
sc-txb_cnt = 1;
else
sc-txb_cnt = 2;
sc-rec_page_start = sc-tx_page_start + sc-txb_cnt * ED_TXBUF_SIZE;
! sc-rec_page_stop = sc-tx_page_start + memsize / ED_PAGE_SIZE;
sc-mem_ring = sc-mem_start + sc-txb_cnt * ED_PAGE_SIZE *
ED_TXBUF_SIZE;
!
! ed_pio_readmem(sc, 0, romdata, 16);
! for (n = 0; n ETHER_ADDR_LEN; n++)
! sc-arpcom.ac_enaddr[n] = romdata[n * (sc-isa16bit + 1)];
#ifdef GWETHER
if (sc-arpcom.ac_enaddr[2] == 0x86) {
--- 1278,1298
* Use one xmit buffer if 16k, two buffers otherwise (if not told
* otherwise).
*/
! if ((sc-mem_size 16384) || (flags ED_FLAGS_NO_MULTI_BUFFERING))
sc-txb_cnt = 1;
else
sc-txb_cnt = 2;
sc-rec_page_start = sc-tx_page_start + sc-txb_cnt * ED_TXBUF_SIZE;
! n = sc-tx_page_start + sc-mem_size / ED_PAGE_SIZE;
! sc-rec_page_stop = (n 0xff) ? 0xff : n;
sc-mem_ring = sc-mem_start + sc-txb_cnt * ED_PAGE_SIZE *
ED_TXBUF_SIZE;
! if (!linksys) {
! ed_pio_readmem(sc, 0, romdata, 16);
! for (n = 0; n ETHER_ADDR_LEN; n++)
! sc-arpcom.ac_enaddr[n] = romdata[n * (sc-isa16bit +
1)];
! }
#ifdef GWETHER
if (sc-arpcom.ac_enaddr[2] == 0x86) {
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: D'oh!
Yes, I looked at it. It's also true that we both (OpenBSD/FreeBSD) have a small memory leak too in this case. NetBSD has none of the problems. -matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: inetd+libwrap and wrapping UDP services
On Tue, Jun 15, 1999 at 08:07:02PM +0200, Sheldon Hearn wrote: On Tue, 15 Jun 1999 20:05:10 +0200, Guido van Rooij wrote: And when you fix that, the wrapper stuff gets invoked for every packet... Even worse than I anticipated. :-) So then we just note in the manpage that only TCP-based services are wrapped? Hmmm..I would just enable the UDP stuff. It is a policy issue, so why not at least giving the functionality. I woul however note in the manpage what the consequences are for nowait UDP services. While you're at it, I'd alos mention what the consequence of the wait option is (i.e. wrapper only for the starting connection). -Guido To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: apmd for FreeBSD
In message 199906151750.caa23...@tasogare.imasy.or.jp Mitsuru IWASAKI writes: : Thanks a lot for your testing. : I'm preparing -current NotePC for testing this. You are most welcome. I'm glad that I could be of assistance. I've wanted something like this for a long time, but never found the time to implement it. : imp P.S. I've put my diffs vs -current at : imp http://www.freebsd.org/~imp/apmd-sys-current.diff.gz : : Thanks. Give my kind regards. No problem. I'm glad that I could be of assistance. Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
to be more precise...
The actual code of interest is:
FreeBSD:
* $Id: nfs_node.c,v 1.28.2.1 1999/06/07 00:04:05 peter Exp $
or
* $Id: nfs_node.c,v 1.29 1999/06/05 05:26:36 peter Exp $
...
/*
* Insert the nfsnode in the hash queue for its new file handle
*/
for (np2 = nhpp-lh_first; np2 != 0; np2 = np2-n_hash.le_next) {
if (mntp != NFSTOV(np)-v_mount || np2-n_fhsize != fhsize ||
bcmp((caddr_t)fhp, (caddr_t)np2-n_fhp, fhsize))
continue;
vrele(vp);
goto retry;
}
OpenBSD:
/* $OpenBSD: nfs_node.c,v 1.13 1999/04/28 09:28:17 art Exp $ */
...
/*
* Insert the nfsnode in the hash queue for its new file handle
*/
for (np2 = nhpp-lh_first; np2 != 0; np2 = np2-n_hash.le_next) {
if (vp-v_mount != NFSTOV(np2)-v_mount ||
fhsize != np2-n_fhsize ||
bcmp((caddr_t)fhp, (caddr_t)np2-n_fhp, fhsize))
continue;
vrele(vp);
goto retry;
}
For OpenBSD and FreeBSD it's a memory leak for the allocated nfsnode *np.
For FreeBSD it's also the locking foop.
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: D'oh!
The problem is that peter is not releasing the nfs_node_hash_lock when he goes to retry, creating a deadlock with himself. Peter, looks like a quick fix commit to me, I'd say just go ahead and do it. Peter is sic transit mundi at the moment, having missed his original flight back from Usenix. This probably calls for another committer (eg. one of the Matts...) -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msm...@freebsd.org \\-- Joseph Merrick \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: D'oh!
On Tue, 15 Jun 1999, Mike Smith wrote: Peter is sic transit mundi at the moment, having missed his original flight back from Usenix. This probably calls for another committer (eg. one of the Matts...) Hmm, a choice of 1 out of 1 unless I missed somthing Peter is sick in transit to mundi? where's mundi? lemme see.. sounds like one of the machines at monash uni. munnari, mullet, mundi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Device drivers (was: looking for a reference manual)
[moved to -hackers; this is more appropriate there] On Tuesday, 15 June 1999 at 20:51:59 +0300, garret.wh...@nokia.com wrote: Hi All! I'm looking to write device drivers for FreeBSD. To this end, I'm searching for a Driver-Kernel interface reference manual for FreeBSD (ordinary BSD should do). (You know, a reference that documents all the low-level library calls and such.) I have one for SVR4 but I'm having trouble finding one for BSD. Anyone know of one? There's nothing that corresponds directly to the System V DDI/DKI manual. Some (but unfortunately not all) kernel functions and structures are described in section 9 of the manual. Look at intro(9) for a start. There's also a tutorial at http://www.freebsd.org/tutorials/ddwg/ddwg.html. But you'll find that you'll have to read a lot of other driver code before you get your driver finished. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Device drivers (was: looking for a reference manual)
you can also find samples in /usr/share/examples/drivers. These may be slightly broken in 4.x On Wed, 16 Jun 1999, Greg Lehey wrote: [moved to -hackers; this is more appropriate there] On Tuesday, 15 June 1999 at 20:51:59 +0300, garret.wh...@nokia.com wrote: Hi All! I'm looking to write device drivers for FreeBSD. To this end, I'm searching for a Driver-Kernel interface reference manual for FreeBSD (ordinary BSD should do). (You know, a reference that documents all the low-level library calls and such.) I have one for SVR4 but I'm having trouble finding one for BSD. Anyone know of one? There's nothing that corresponds directly to the System V DDI/DKI manual. Some (but unfortunately not all) kernel functions and structures are described in section 9 of the manual. Look at intro(9) for a start. There's also a tutorial at http://www.freebsd.org/tutorials/ddwg/ddwg.html. But you'll find that you'll have to read a lot of other driver code before you get your driver finished. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Holy cow - path component freeing a mess? (was Re: D'oh!)
This is totally screwed up: The rules used to determine whether a path component buffer ( struct componentname, sys/namei.h ) is freed by a VOP routine or not are idiotic. As far as I can tell, the rule is: * if no error is returned free the path component buffer, but only if the SAVESTART flag is not set. * If an error is returned, free the path component buffer whether SAVESTART is set or not. Combine this with the callers which decide whether to set SAVESTART, and the result is an extremely fragile mess. Combine this with VOP_ABORTOP's operation ( which frees the path component if SAVESTART is not set ) and it gets even worse. Confused yet? At the very least, anyone who zfree's a path component should clear the HASBUF flag so sanity checks can be added to the code. The nfs_serv.c code is unnecessarily complex due to this junkiness. I would like to fix this in the tree and add sanity checks. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Intel 82559 Suppored?
Is the 82559 ethernet controller supported under Freebsd 3.2? Dennis To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Intel 82559 Suppored?
Is the 82559 ethernet controller supported under Freebsd 3.2? Yes. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Holy cow - path component freeing a mess? (was Re: D'oh!)
Umm, okay but I'm a little confused about how the zfree I'm adding to nfs_nget falls under this. Am I being really stupid here? On Tue, 15 Jun 1999, Matthew Dillon wrote: This is totally screwed up: The rules used to determine whether a path component buffer ( struct componentname, sys/namei.h ) is freed by a VOP routine or not are idiotic. As far as I can tell, the rule is: * if no error is returned free the path component buffer, but only if the SAVESTART flag is not set. * If an error is returned, free the path component buffer whether SAVESTART is set or not. Combine this with the callers which decide whether to set SAVESTART, and the result is an extremely fragile mess. Combine this with VOP_ABORTOP's operation ( which frees the path component if SAVESTART is not set ) and it gets even worse. Confused yet? At the very least, anyone who zfree's a path component should clear the HASBUF flag so sanity checks can be added to the code. The nfs_serv.c code is unnecessarily complex due to this junkiness. I would like to fix this in the tree and add sanity checks. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Holy cow - path component freeing a mess? (was Re: D'oh!)
talk to terry on this topic :-) He has a set of patches that straighten all this out julian On Tue, 15 Jun 1999, Matthew Dillon wrote: This is totally screwed up: The rules used to determine whether a path component buffer ( struct componentname, sys/namei.h ) is freed by a VOP routine or not are idiotic. As far as I can tell, the rule is: * if no error is returned free the path component buffer, but only if the SAVESTART flag is not set. * If an error is returned, free the path component buffer whether SAVESTART is set or not. Combine this with the callers which decide whether to set SAVESTART, and the result is an extremely fragile mess. Combine this with VOP_ABORTOP's operation ( which frees the path component if SAVESTART is not set ) and it gets even worse. Confused yet? At the very least, anyone who zfree's a path component should clear the HASBUF flag so sanity checks can be added to the code. The nfs_serv.c code is unnecessarily complex due to this junkiness. I would like to fix this in the tree and add sanity checks. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Holy cow - path component freeing a mess? (was Re: D'oh!)
:Umm, okay but I'm a little confused about how the zfree I'm adding to :nfs_nget falls under this. Am I being really stupid here? it's unrelated. I was starting a new thread. I have finished fixing up nfs_serv.c and am now testing it. Most of the procedures required significant adjustments to catch all the problems - mainly due to the various NFS macros in nfsm_subs.h doing 'goto nfsmout;'. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Holy cow - path component freeing a mess? (was Re: D'oh!)
:Umm, okay but I'm a little confused about how the zfree I'm adding to :nfs_nget falls under this. Am I being really stupid here? it's unrelated. I was starting a new thread. I have finished fixing up nfs_serv.c and am now testing it. Most of the procedures required significant adjustments to catch all the problems - mainly due to the various NFS macros in nfsm_subs.h doing 'goto nfsmout;'. Way to go! I was hoping this would happen... it is the miracle of Open Source. I am a bit sad that I'm not doing any of the stuff now though :(, you guys are just too gosh darn quick. Seriously though... when are we likely to see this stuff hit -STABLE? I would like to to dig through your nfs_serv.c at some point before it gets commited too. There are a couple of other NFSv3 bugs that I have been tracking and I would like to see if this addresses those. -- David Cross | email: cro...@cs.rpi.edu Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Holy cow - path component freeing a mess? (was Re: D'oh!)
:Way to go! I was hoping this would happen... it is the miracle of Open Source. :I am a bit sad that I'm not doing any of the stuff now though :(, you guys :are just too gosh darn quick. : :Seriously though... when are we likely to see this stuff hit -STABLE? I would :like to to dig through your nfs_serv.c at some point before it gets commited :too. There are a couple of other NFSv3 bugs that I have been tracking and I :would like to see if this addresses those. : :-- :David Cross | email: cro...@cs.rpi.edu The differences between -current and -stable for nfs_serv.c and nfs_subs.c are relatively minor. Once we've life tested the hell out of it in current, it should be easy to MFC into stable. Maybe 3 weeks total. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Holy cow - path component freeing a mess? (was Re: D'oh!)
The differences between -current and -stable for nfs_serv.c and nfs_subs.c are relatively minor. Once we've life tested the hell out of it in current, it should be easy to MFC into stable. Maybe 3 weeks total. Hmm... that is a bit long for us... 3 weeks, 21 days at 1.7 day/panic = 0.59 Panic/Day == 21 (day) * 0.59(day/panic) [remeber to check your units ;] that's another 12 panics for us (if they keep up at the current rate). Luckily since we have backed down to NFSv2 we are a bit more stable. The only reason the server went down today is because the IDE disk decided to flake out. It was amazing, even though the OS disk was dead it still continued to serve some NFS requests (from different partitions of course :) Don't get me wrong, I agree this is the correct procedure, but I plan to roll my own nfs_serv.c untill it gets MFC-ed... and I'll be able to provide you with some real world test results of the new code on -STABLE. -- David Cross | email: cro...@cs.rpi.edu Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
RE: DHCP, arp and de0
On 13-Jun-99 Daniel J. O'Connor wrote: Hi, I have tried getting my system to use DHCP on my local network, but I'm having trouble. If I don't use DHCP everything works fine, but if I use DHCP I get the following messages appearing in my log file when I use ESD, and try and ping my LAN IP. Jun 13 17:35:21 guppy /kernel: arplookup 127.0.0.1 failed: could not allocate llinfo Jun 13 17:35:21 guppy /kernel: arpresolve: can't allocate llinfo for 127.0.0.1rt I notcied also that the arp table doesn't have an entry for my IP when I use DHCP. When I don't use DHCP I have a line like guppy.dons.net.au (203.31.81.9) at 0:80:ad:16:77:3e permanent [ethernet] in the arp table, but its not there when I use DHCP. I can't add it by hand either. I am running -current as of this morning (ie 12 Jun 10:30am GMT), and I have a Digital 21140 base 10/100 card. It has 2 ports, one for 10 and the other for 100 mbits (lame). Personally I suspect the driver since I've had other strangness with arp and this card when I try and change media, but I could be way off base. Any ideas? Are you using the built-in dhcp client (/sbin/dhclient)? If so, what does the output look like during boot up? What does 'ifconfig -i de0' show? Also, do you have a lease in /var/db/dhcp.leases? --- John Baldwin jobal...@vt.edu -- http://members.freedomnet.com/~jbaldwin/ PGP Key: http://members.freedomnet.com/~jbaldwin/pgpkey.asc Power Users Use the Power to Serve! - http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Holy cow - path component freeing a mess? (was Re: D'oh!)
:Hmm... that is a bit long for us... 3 weeks, 21 days at 1.7 day/panic = :0.59 Panic/Day == 21 (day) * 0.59(day/panic) [remeber to check your units ;] :... :David Cross | email: cro...@cs.rpi.edu I'll have patches on my site in a few days. I just meant time till it was actually committed into -stable. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: [Call for review] init(8): new feature
Arun Sharma wrote: While we're on the init topic, is there any strong feeling here about BSD /etc/rc* scripts Vs SysV ? The nice thing about SysV initscripts is the ability to start and stop any service that I like. That's fine -- there are lots of ways to start and stop any service you like without involving SysV init. - mark Mark Newton Email: new...@internode.com.au (W) Network Engineer Email: new...@atdot.dotat.org (H) Internode Systems Pty Ltd Desk: +61-8-82232999 Network Man - Anagram of Mark Newton Mobile: +61-416-202-223 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
RE: DHCP, arp and de0
On 15-Jun-99 John Baldwin wrote: Are you using the built-in dhcp client (/sbin/dhclient)? If so, what does output look like during boot up? What does 'ifconfig -i de0' show? Also, you have a lease in /var/db/dhcp.leases? I am using /sbin/dhclient de0 to get a lease, and the config file is empty except for comments. The output looks OK when it boots up, but I don't have an exact copy. It DOES get a lease fine, but for some reason it isn't entered into the arp table :( Err.. ifconfig -i de0 isn't legal :) --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: IR Remote for AverMedia and FlyVideo
Josef Karthauser writes: I've got a phototransistor plugged into my DTR line on the serial port. Is there any working software for FreeBSD for utilising this? (I want to never lose a remote control again!) Oh My Goodness! I don't know whether to laugh or cry. Can somebody get me started with links to whatever online IR technology is out there? I am in need of a bunch of IR remote control units which can be controlled via serial port or other simple computerized means. While in the past One For All made inexpensive IR remote controls with a serial port, they changed the design about 4 years ago and refused to publish the spec. Do not know if they still include any kind of serial port in current models. Wouldn't do me any good unless I have documentation. As for phototransistor plugged into my DTR line, this is a job for a $2 microcontroller, not a task for a multiuser multitasking OS. I *think* you can start at http://www.mcu.motsps.com/ and follow the 68HC05 family and find a reference design using a 68HC705K IR controller. It is a very simple design and does very few commands. Its not intented to be a build to print IR controller. Only a example to get one started. The code is given for generating IR commands. The 68HC705K family features IRQ and pullups on some of its I/O pins allowing one to connect to a keyboard with zero external components. Probably would want to substitute another '05, possibly one with a serial port. Other Motorola app notes provide example code to implement UARTs in software. Also at the same site is a DOS-based 68HC05 assembler. I've been meaning to see if it runs under doscmd. -- David Kelly N4HHE, dke...@nospam.hiwaay.net = The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
RE: IR Remote for AverMedia and FlyVideo
I bought a one-for-all remote that I drove from FreeBSD just in the last year or two. You might try www.smarthome.com. I bought the remote, cable, and docs for how to use it for under US $100. They also have RS232 learning IR devices for $180. Expensive, but I wasn't willing to do the electronics work. -Chris -Original Message- From: David Kelly [SMTP:dke...@hiwaay.net] Sent: Tuesday, June 15, 1999 8:48 PM To: Josef Karthauser Cc: Roger Hardiman; multime...@freebsd.org; hack...@freebsd.org; s...@freebsd.org Subject: Re: IR Remote for AverMedia and FlyVideo Josef Karthauser writes: I've got a phototransistor plugged into my DTR line on the serial port. Is there any working software for FreeBSD for utilising this? (I want to never lose a remote control again!) Oh My Goodness! I don't know whether to laugh or cry. Can somebody get me started with links to whatever online IR technology is out there? I am in need of a bunch of IR remote control units which can be controlled via serial port or other simple computerized means. While in the past One For All made inexpensive IR remote controls with a serial port, they changed the design about 4 years ago and refused to publish the spec. Do not know if they still include any kind of serial port in current models. Wouldn't do me any good unless I have documentation. As for phototransistor plugged into my DTR line, this is a job for a $2 microcontroller, not a task for a multiuser multitasking OS. I *think* you can start at http://www.mcu.motsps.com/ and follow the 68HC05 family and find a reference design using a 68HC705K IR controller. It is a very simple design and does very few commands. Its not intented to be a build to print IR controller. Only a example to get one started. The code is given for generating IR commands. The 68HC705K family features IRQ and pullups on some of its I/O pins allowing one to connect to a keyboard with zero external components. Probably would want to substitute another '05, possibly one with a serial port. Other Motorola app notes provide example code to implement UARTs in software. Also at the same site is a DOS-based 68HC05 assembler. I've been meaning to see if it runs under doscmd. -- David Kelly N4HHE, dke...@nospam.hiwaay.net = The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-multimedia in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
RE: DHCP, arp and de0
On 16-Jun-99 Daniel O'Connor wrote: On 15-Jun-99 John Baldwin wrote: Are you using the built-in dhcp client (/sbin/dhclient)? If so, what does output look like during boot up? What does 'ifconfig -i de0' show? Also, you have a lease in /var/db/dhcp.leases? I am using /sbin/dhclient de0 to get a lease, and the config file is empty except for comments. The output looks OK when it boots up, but I don't have an exact copy. It DOES get a lease fine, but for some reason it isn't entered into the arp table :( Err.. ifconfig -i de0 isn't legal :) Whoops.. just ifconfig de0. Have you tried using the interface? We use dhcp for a lab I help run, and 'arp -a' on the clients does not show an entry for the local de0 card they have installed, but they work fine regardless. Do you have a route for 127.0.0.1 in your route table (netstat -rn), there should be one that just points to itself so, AFAIK, it shouldn't be arp'ing for that address. --- John Baldwin jobal...@vt.edu -- http://members.freedomnet.com/~jbaldwin/ PGP Key: http://members.freedomnet.com/~jbaldwin/pgpkey.asc Power Users Use the Power to Serve! - http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: RE: DHCP, arp and de0
From: John Baldwin jobal...@vt.edu Date: 1999-06-15 16:23:24 -0700 To: Daniel J. O'Connor dar...@dons.net.au Subject: RE: DHCP, arp and de0 Cc: freebsd-hackers@FreeBSD.ORG In-reply-to: xfmail.990613182527.dar...@dons.net.au X-Priority: 3 (Normal) Delivered-to: freebsd-hackers@freebsd.org X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Loop: FreeBSD.ORG On 13-Jun-99 Daniel J. O'Connor wrote: Hi, I have tried getting my system to use DHCP on my local network, but I'm having trouble. If I don't use DHCP everything works fine, but if I use DHCP I get the following messages appearing in my log file when I use ESD, and try and ping my LAN IP. Jun 13 17:35:21 guppy /kernel: arplookup 127.0.0.1 failed: could not allocate llinfo Jun 13 17:35:21 guppy /kernel: arpresolve: can't allocate llinfo for 127.0.0.1rt I'm not sure this is relevant, but the loopback address should *not* be fed to ARP. That's attached to the loopback interface (lo0), and shouldn't be seen on any wire. Could be your config is seriously fouled up. Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Manager, CoreOS Networking| Men are from Earth. Apple Computer, Inc. | Women are from Earth. 2 Infinite Loop | Deal with it. Cupertino, CA 95014 | *-*---* To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: IR Remote for AverMedia and FlyVideo
Christopher Sedore writes: I bought a one-for-all remote that I drove from FreeBSD just in the last year or two. You might try www.smarthome.com. I bought the remote, cable, and docs for how to use it for under US $100. They also have RS232 learning IR devices for $180. Expensive, but I wasn't willing to do the electronics work. Familiar with www.smarthome.com. Bought docs from them when the OFA-6 changed to a newer OFA-6. A problem I've always had with the OFA-6 was that I couldn't hold a button down over the serial port. Could only momentarily press it. Found something interesting, http://www.smarthome.com/1143.html, IBM Home Director X10 Starter Kit. Appears to be software for programming a fancy IR/RF remote control via serial port. Then you can turn the computer off and the remote control will execute preprogramed instructions at the assigned time. $39.95. Now it doesn't really say the IR/RF remote control has the serial port but I don't see anything else. It does say you can turn the computer off after programming your events. So it has to happen outside of the computer. Guess I'm going to have to buy one to find out. On second thought it appears SmartHome is simply not picturing the Home Director controller, which is the component that connects to the PC serial port. Search for IBM Home Director on Yahoo! yielded lots of accurate hits. At the moment I don't see a path from the computer to an IR appliance. Maybe there is one. Maybe not. But mostly the IR/RF remote control is there to provide a cordless way for a human to do the X10 stuff. -- David Kelly N4HHE, dke...@nospam.hiwaay.net = The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
VOP_*() routines, lookup(), and namei() leave garbage pointers on error
Bleh. More fragility. VOP_*() routines, lookup(), and namei() leave garbage pointers in nameidata and returned-vnode structures when they return an error. They really ought to NULL-out those garbage pointers. It's on my list to fix. It makes it difficult for the NFS code to keep track of its state. That plus the almost total lack of state tracking for the path name component allocation state, which makes it difficult to sanity-check the zfree's. For example, if lookup() returns an error it may leave an invalid ni_dvp pointer in the nameidata. VOP_SYMLINK returns an invalid vp ( all callers of VOP_SYMLINK just ignore it, but that still doesn't make it right ), and namei() also has similar problems when it returns na error. -Matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
RE: DHCP, arp and de0
On 16-Jun-99 John Baldwin wrote: Whoops.. just ifconfig de0. Have you tried using the interface? We use for a lab I help run, and 'arp -a' on the clients does not show an entry for the local de0 card they have installed, but they work fine regardless. Do have a route for 127.0.0.1 in your route table (netstat -rn), there should one that just points to itself so, AFAIK, it shouldn't be arp'ing for that address. Well I have a netstat -nr from when it was using DHCP and when it wasn't and the only difference is the 'Refs' for 127.0.0.1 was 3 for DHCP and 2 for static. The interface works OK for somethings, but for example I can't run 'esd', and whenever I try and ping the address assigned to the ethernet card I get Jun 13 17:35:21 guppy /kernel: arplookup 127.0.0.1 failed: could not allocate llinfo Jun 13 17:35:21 guppy /kernel: arpresolve: can't allocate llinfo for 127.0.0.1rt every ping packet sent. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: RE: DHCP, arp and de0
On 16-Jun-99 Justin C. Walker wrote: I'm not sure this is relevant, but the loopback address should *not* be fed to ARP. That's attached to the loopback interface (lo0), and shouldn't be seen on any wire. Could be your config is seriously fouled up. Yes, but how :) The loopback device is configured properly etc.. Its quite strange :-/ --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: [Call for review] init(8): new feature
Mark Newton new...@internode.com.au writes: Arun Sharma wrote: While we're on the init topic, is there any strong feeling here about BSD /etc/rc* scripts Vs SysV ? The nice thing about SysV initscripts is the ability to start and stop any service that I like. That's fine -- there are lots of ways to start and stop any service you like without involving SysV init. Like sending a signal to the process providing the service ? The problem with that approach is, the signal you send and the clean up you do is non-standard for each service and having a standard interface: /etc/rc.d/service stop|start|restart makes it standard. -Arun To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: [Call for review] init(8): new feature
Arun Sharma wrote: Mark Newton new...@internode.com.au writes: Arun Sharma wrote: While we're on the init topic, is there any strong feeling here about BSD /etc/rc* scripts Vs SysV ? The nice thing about SysV initscripts is the ability to start and stop any service that I like. That's fine -- there are lots of ways to start and stop any service you like without involving SysV init. Like sending a signal to the process providing the service ? The problem with that approach is, the signal you send and the clean up you do is non-standard for each service and having a standard interface: There are lots of ways to start and stop any service you like without relying on sending a signal to a process and without involving SysV init. This topic has been canvassed so many times by so many people that I can only suggest that you run off to the archives and read about it there. - mark Mark Newton Email: new...@internode.com.au (W) Network Engineer Email: new...@atdot.dotat.org (H) Internode Systems Pty Ltd Desk: +61-8-82232999 Network Man - Anagram of Mark Newton Mobile: +61-416-202-223 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: [Call for review] init(8): new feature
They SysV way is more elegant and less error prone for bad typist. Graphical tools can be used to interface with these quite easily. It also also easy to automate installations via installation mechanisms. I don't think I agree that it is a bad idea because it is associated with SysV... On 15 Jun 1999, Arun Sharma wrote: Date: 15 Jun 1999 19:54:51 -0700 From: Arun Sharma adsha...@home.com To: Mark Newton new...@internode.com.au Cc: hack...@freebsd.org Subject: Re: [Call for review] init(8): new feature Mark Newton new...@internode.com.au writes: Arun Sharma wrote: While we're on the init topic, is there any strong feeling here about BSD /etc/rc* scripts Vs SysV ? The nice thing about SysV initscripts is the ability to start and stop any service that I like. That's fine -- there are lots of ways to start and stop any service you like without involving SysV init. Like sending a signal to the process providing the service ? The problem with that approach is, the signal you send and the clean up you do is non-standard for each service and having a standard interface: /etc/rc.d/service stop|start|restart makes it standard. -Arun To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
how do I install driver examples?
On my 2.2.7 system I have this directory: /usr/share/examples/drivers This is not on my 3.2S system. I have the 3.1 4 cd set can anyone tell me what I need to install in order get the drivers extracted from my 3.1 cd? Thanks, Wayne To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Typo: sys/pci/pcisupport.c
4.0-CURRENT: sys/pci/pcisupport.c: 955:/* VIA Technologies -- vendor 0x1106 / 956:case 0x05861106: /* south bridge section */ 957:return (VIA 82C586 PCI-ISA bridge); This is cute. Moo. Daniel -- dba...@cuckoo.com - Senior CuckooNet Consultant - http://www.cuckoo.com/daniel/ pgpeZn1sYRroo.pgp Description: PGP signature
Re: [Call for review] init(8): new feature
Wayne Cuddy wrote: They SysV way is more elegant and less error prone for bad typist. ... and has absolutely no way of encoding interdependencies between services (or any concept of a service at all, other than as after-the-fact hacks). What happens to your NFS services when you do /etc/init.d/inetsvc stop; /etc/init.d/inetsvc start on a Sun? What *should* happen on a notebook computer when you start it without its pccard ethernet device plugged in? Should certain network services not be started at all, or should they be delayed until after PPP comes up? Isn't that a question that can only be answered by the individual service? (like, DHCP wouldn't need to start at all when PPP comes up, but your web server might need to be restarted to listen to a new IP address). Graphical tools can be used to interface with these quite easily. ... also true for any other well-designed interface. It also also easy to automate installations via installation mechanisms. Also true for any other well-designed interface. SysV's mechanism is not a well-designed interface. Sure, it has its strengths, and it makes certain tasks easy, but it's not the only answer that has strengths and simplicity. I don't think I agree that it is a bad idea because it is associated with SysV... Neither do I; that issue hasn't been broached in this discussion to date. I think it's a bad idea because it's an intrinsically bad idea. It seems to me that every time this issue comes up people say, We need something better than rc.local/rc.conf for boot-time configuration. SysV has certain attributes we don't have; so let's use SysV! It's like the politician's mantra: SOMETHING must be done! This random solution counts as `something', so let's implement this random solution. Let's not. Several people have given this matter serious thought and have come up with some excellent ideas, some of which have been implmenented as a test platform. Again I'd suggest that anyone interested in following this up consults the archives first, because the last thing we need is to have the mailing lists rehash the same ground *again* less than three months after the last time we rehashed it. [ a note to whoever it is that's replying to this message: you will no doubt delete this text in your reply, because it's stressing that you should CONSULT THE ARCHIVES. have you consulted them? if not, please, please, please exit your editor without saving your response, and consult them. thank you for your cooperation. normal service will resume shortly. ] - mark Mark Newton Email: new...@internode.com.au (W) Network Engineer Email: new...@atdot.dotat.org (H) Internode Systems Pty Ltd Desk: +61-8-82232999 Network Man - Anagram of Mark Newton Mobile: +61-416-202-223 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: how do I install driver examples?
On Tue, 15 Jun 1999, Wayne Cuddy wrote: On my 2.2.7 system I have this directory: /usr/share/examples/drivers This is not on my 3.2S system. I have the 3.1 4 cd set can anyone tell me what I need to install in order get the drivers extracted from my 3.1 cd? They are on cdrom2. # cd /; (cd /cdrom; tar cvf - usr/share/examples/drivers ) | tar xvf - should work. David Scheidt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: [Call for review] init(8): new feature
adsha...@home.com wrote: Like sending a signal to the process providing the service ? The problem with that approach is, the signal you send and the clean up you do is non-standard for each service and having a standard interface: /etc/rc.d/service stop|start|restart makes it standard. I think we need to use /usr/local/etc/rc.d/service.sh stop|start|restart # Yes, We modify some ports to support start,stop. MIHIRA Sanpei Yoshiro To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: [Call for review] init(8): new feature
pgpnad5Bmmg3c.pgp Description: signed PGP message
