Date: Sat, 8 Jul 1995 21:41:54 -0700 From: "Jonathan M. Bresler" <jmb> To: hackers Message-ID: <199507090441.VAA17956@freefall.cdrom.com>
next in thread | raw e-mail | index | archive | help
>From owner-freebsd-hackers Sat Jul 8 02:42:57 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.10/8.6.6) id CAA15222
for hackers-outgoing; Sat, 8 Jul 1995 02:42:57 -0700
Received: from jau.csc.fi (root@jau.csc.fi [193.166.1.196])
by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id CAA15146
for <hackers@freebsd.org>; Sat, 8 Jul 1995 02:42:46 -0700
Received: (from jau@localhost) by jau.csc.fi (8.6.11/8.6.9) id AAA00799 for hackers@freebsd.org; Sat, 8 Jul 1995 00:42:04 +0300
From: Jukka Ukkonen <jau@jau.csc.fi>
Message-Id: <199507072142.AAA00799@jau.csc.fi>
Subject: new getsid(2) system call for freebsd...
To: hackers@freebsd.org
Date: Sat, 8 Jul 1995 00:42:04 +0300 (EET DST)
Latin-Date: Simbata VIII Iulie a.d. MCMXCV
Organization: Private person
Phone: +358-0-4573208 (work)
Reply-To: ukkonen@aphrodite.funet.fi
Content-Conversion: prohibited
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Content-Length: 9175
Sender: hackers-owner@freebsd.org
Precedence: bulk
Hi all!
A couple of days ago I had a sudden moment of inspiration and
I added an initial version of a new SVR4 style system call
getsid(2) to FreeBSD.
In fact the same piece of code should be just about all right
also for other variants of BSD based systems, if anyone cares
to import it to any of them.
The rationale for such a new system call is first and foremost
completeness and symmetry. The second reason is the fact that
X/Open might begin requiring such a service in their XPG, which
might become a portability issue one day. The third point is
that now and then there are things that would be somewhat easier
to do, if such an interface were available, and moreover it is
practically impossible to do exactly the same thing in a user
mode subroutine.
My version is based on my interpretation of what has been said
about getsid(2) in SGI Irix-6.0 manual pages.
The idea is that the caller can ask the session id (actually the
PID of the session leader) of any process in the system, if the
caller runs with the EUID of root. Any process can also query
the SID of any other process having the same EUID as the caller
or that of any of it's own descendants. Naturally a process can
also query it's own SID by specifying it's own PID or 0 as the
parameter.
The external prototype of the system call is
extern pid_t getsid (pid_t target_process_id);
In the current implementation I just grabbed syscall number 205
for this purpose, because it was the first one which I noticed
not to be previously allocated for any other purpose. Some of
you may certainly argue that some other code should be used
instead, and some of you will supposedly even argue against
having such a system call at all. Anyway you have now seen my
reasoning for including getsid(2) in the system distribution,
and the game is yours.
You are free to change the syscall number and other details
or even drop my patch, if you like. I could imagine at least
one potential enhancement right now. The SID could maybe be
stored in the session structure itself, so that getsid(2)
would not depend on the original session leader or it's zombie
being present in the system just in case a child process had
survived after the termination of the original session leader.
In my own system I will maintain my idea of which processes are
allowed to use getsid(2) to query SIDs of other processes, which
is as close to SVR4 (and supposedly also X/Open) definition I
could get based on the documentation I had, unless or until
someone is able to present a reasonably good basis for different
access rules.
The patch (diff -c) to all the minor but necessary changes
is attached at the end of this message.
(Oh yes, don't even ask. It should be obvious. I did not run
makesyscalls.sh but made the changes to the .h files manually,
though I also modified the syscalls.master file appropriately.)
Cheers,
// jau
------
/ Jukka A. Ukkonen, FUNET / Centre for Scientific Computing
/__ M.Sc. (sw-eng & cs) Tel: (Home) +358-0-578628
/ Internet: ukkonen@csc.fi (Work) +358-0-4573208
/ Internet: jau@funet.fi (Mobile) +358-400-606671
v X.400: c=fi, admd=fumail, no prmd, org=csc, pn=jukka.ukkonen
------------------------------ clip clip ------------------------------
*** /usr/src/lib/libc/sys/Makefile.inc.orig Sat May 27 07:17:04 1995
--- /usr/src/lib/libc/sys/Makefile.inc Fri Jul 7 01:46:41 1995
***************
*** 17,23 ****
fchflags.o fchmod.o fchown.o fcntl.o flock.o fpathconf.o fstat.o \
fstatfs.o fsync.o getdirentries.o getdtablesize.o getegid.o \
geteuid.o getfh.o getfsstat.o getgid.o getgroups.o getitimer.o \
! getpeername.o getpgrp.o getpid.o getppid.o getpriority.o \
getrlimit.o getrusage.o getsockname.o getsockopt.o gettimeofday.o \
getuid.o ioctl.o kill.o ktrace.o lfs_bmapv.o lfs_markv.o \
lfs_segclean.o lfs_segwait.o link.o listen.o lstat.o \
--- 17,23 ----
fchflags.o fchmod.o fchown.o fcntl.o flock.o fpathconf.o fstat.o \
fstatfs.o fsync.o getdirentries.o getdtablesize.o getegid.o \
geteuid.o getfh.o getfsstat.o getgid.o getgroups.o getitimer.o \
! getpeername.o getpgrp.o getpid.o getppid.o getsid.o getpriority.o \
getrlimit.o getrusage.o getsockname.o getsockopt.o gettimeofday.o \
getuid.o ioctl.o kill.o ktrace.o lfs_bmapv.o lfs_markv.o \
lfs_segclean.o lfs_segwait.o link.o listen.o lstat.o \
*** /usr/include/sys/syscall.h.orig Sun Apr 23 15:22:06 1995
--- /usr/include/sys/syscall.h Fri Jul 7 01:12:45 1995
***************
*** 191,193 ****
--- 191,194 ----
#define SYS___sysctl 202
#define SYS_mlock 203
#define SYS_munlock 204
+ #define SYS_getsid 205
*** /usr/include/sys/syscall-hide.h.orig Fri Jul 7 01:14:16 1995
--- /usr/include/sys/syscall-hide.h Fri Jul 7 01:13:22 1995
***************
*** 214,216 ****
--- 214,217 ----
HIDE_BSD(__sysctl)
HIDE_BSD(mlock)
HIDE_BSD(munlock)
+ HIDE_BSD(getsid)
*** /sys/kern/init_sysent.c.orig Fri Jul 7 09:27:51 1995
--- /sys/kern/init_sysent.c Fri Jul 7 09:28:25 1995
***************
*** 177,182 ****
--- 177,183 ----
int __sysctl();
int mlock();
int munlock();
+ int getsid();
int lkmnosys();
#ifdef COMPAT_43
***************
*** 484,490 ****
{ 6, __sysctl }, /* 202 = __sysctl */
{ 2, mlock }, /* 203 = mlock */
{ 2, munlock }, /* 204 = munlock */
! { 0, nosys }, /* 205 = nosys */
{ 0, nosys }, /* 206 = nosys */
{ 0, nosys }, /* 207 = nosys */
{ 0, nosys }, /* 208 = nosys */
--- 485,492 ----
{ 6, __sysctl }, /* 202 = __sysctl */
{ 2, mlock }, /* 203 = mlock */
{ 2, munlock }, /* 204 = munlock */
! /* { 0, nosys }, 205 = nosys */
! { 1, getsid }, /* 205 = getsid */
{ 0, nosys }, /* 206 = nosys */
{ 0, nosys }, /* 207 = nosys */
{ 0, nosys }, /* 208 = nosys */
*** /sys/kern/kern_prot.c.orig Fri Jul 7 09:27:51 1995
--- /sys/kern/kern_prot.c Fri Jul 7 19:13:47 1995
***************
*** 95,100 ****
--- 95,157 ----
return (0);
}
+ /*
+ * External signature: pid_t getsid (pid_t);
+ *
+ * SVR4 style system call getsid()
+ * exists only because this is a trick which is practically
+ * impossible to do from within a user space subroutine.
+ * Often this kind of information is useful to have though,
+ * and probably X/Open will require this anyway.
+ */
+
+ struct getsid_args {
+ pid_t pid;
+ };
+
+ /* ARGSUSED */
+ int
+ getsid (p, uap, retval)
+ struct proc *p;
+ struct getsid_args *uap;
+ int *retval;
+ {
+ /*
+ * Currently the expression
+ *
+ * *retval = p->p_session->s_leader->p_pid;
+ *
+ * is an easier to read form of...
+ *
+ * *retval = p->p_pgrp->pg_session->s_leader->p_pid;
+ */
+
+ register struct proc *targp; /* taget process */
+
+ if (! uap->pid || (uap->pid == p->p_pid))
+ targp = p;
+ else {
+ if (! (targp = pfind(uap->pid)))
+ return (ESRCH);
+
+ /*
+ * For true pedantics only...
+ * 1. Either current proc must be owned by root,
+ * 2. or by the same effective uid as the target,
+ * 3. or the target must be a descendant of the caller.
+ */
+ if (p->p_cred->pc_ucred->cr_uid
+ && (targp->p_cred->pc_ucred->cr_uid
+ != p->p_cred->pc_ucred->cr_uid)
+ && ! inferior(targp))
+ return (EPERM);
+ }
+
+ *retval = targp->p_session->s_leader->p_pid;
+
+ return (0);
+ }
+
/* ARGSUSED */
int
getuid(p, uap, retval)
*** /sys/kern/syscalls.c.orig Fri Jul 7 09:27:51 1995
--- /sys/kern/syscalls.c Fri Jul 7 09:28:25 1995
***************
*** 246,252 ****
"__sysctl", /* 202 = __sysctl */
"mlock", /* 203 = mlock */
"munlock", /* 204 = munlock */
! "#205", /* 205 = nosys */
"#206", /* 206 = nosys */
"#207", /* 207 = nosys */
"#208", /* 208 = nosys */
--- 246,253 ----
"__sysctl", /* 202 = __sysctl */
"mlock", /* 203 = mlock */
"munlock", /* 204 = munlock */
! /* "#205", 205 = nosys */
! "getsid", /* 205 = getsid */
"#206", /* 206 = nosys */
"#207", /* 207 = nosys */
"#208", /* 208 = nosys */
*** /sys/kern/syscalls.master.orig Fri Jul 7 09:27:51 1995
--- /sys/kern/syscalls.master Fri Jul 7 09:28:25 1995
***************
*** 277,283 ****
; here allows to avoid one in libc/sys/Makefile.inc.
203 STD 2 BSD mlock
204 STD 2 BSD munlock
! 205 UNIMPL 0 NOHIDE nosys
206 UNIMPL 0 NOHIDE nosys
207 UNIMPL 0 NOHIDE nosys
208 UNIMPL 0 NOHIDE nosys
--- 277,284 ----
; here allows to avoid one in libc/sys/Makefile.inc.
203 STD 2 BSD mlock
204 STD 2 BSD munlock
! ; 205 UNIMPL 0 NOHIDE nosys
! 205 STD 1 BSD getsid
206 UNIMPL 0 NOHIDE nosys
207 UNIMPL 0 NOHIDE nosys
208 UNIMPL 0 NOHIDE nosys
*** /usr/include/unistd.h.orig Sun Jun 4 16:45:57 1995
--- /usr/include/unistd.h Fri Jul 7 08:25:45 1995
***************
*** 76,81 ****
--- 76,82 ----
pid_t getpgrp __P((void));
pid_t getpid __P((void));
pid_t getppid __P((void));
+ pid_t getsid __P((pid_t));
uid_t getuid __P((void));
int isatty __P((int));
int link __P((const char *, const char *));
>From owner-freebsd-hackers Sat Jul 8 02:46:00 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.10/8.6.6) id CAA16177
for hackers-outgoing; Sat, 8 Jul 1995 02:46:00 -0700
Received: from eikon.regent.e-technik.tu-muenchen.de (root@eikon.regent.e-technik.tu-muenchen.de [129.187.42.3])
by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id CAA16151
; Sat, 8 Jul 1995 02:45:52 -0700
Received: from vector.eikon.e-technik.tu-muenchen.de ([129.187.142.36]) by eikon.regent.e-technik.tu-muenchen.de with SMTP id <55318>; Sat, 8 Jul 1995 11:45:46 +0200
Received: from localhost (localhost [127.0.0.1]) by vector.eikon.e-technik.tu-muenchen.de (8.6.11/8.6.9) with SMTP id LAA02553; Sat, 8 Jul 1995 11:42:42 +0200
Message-Id: <199507080942.LAA02553@vector.eikon.e-technik.tu-muenchen.de>
X-Authentication-Warning: vector.eikon.e-technik.tu-muenchen.de: Host localhost didn't use HELO protocol
To: "Jordan K. Hubbard" <jkh@freebsd.org>
cc: Jeffrey Hsu <hsu@freebsd.org>, hackers@freebsd.org
Subject: Re: Proposal to change name of this list to a less embarrassing one
In-reply-to: Your message of "Fri, 07 Jul 1995 09:26:02 +0200."
<17268.805101962@time.cdrom.com>
Date: Sat, 8 Jul 1995 11:42:41 +0200
From: "Julian Stacey <jhs@freebsd.org>" <jhs@vector.eikon.e-technik.tu-muenchen.de>
Sender: hackers-owner@freebsd.org
Precedence: bulk
> To: Jeffrey Hsu <hsu@freebsd.org>
> From: "Jordan K. Hubbard" <jkh@freebsd.org>
> but the almost overwhelming concensus right now seems to
> be "leave it alone" and so I believe we will.
Strange, I had got the impression it was about 50 / 50 !
( I'd even been thinking it might be worth asking core to consider
calling for a vote on a name change in perhaps a week, after anyone away had
had time to catch up on mail (no rush about this after all :-) )
> hackers@freebsd.org it stays,
obviously we'd need a sizeable majority for a change
> I see no reason why that someone couldn't just
> create a local gateway to the mailing list using a different name.
Well, that person would have to have a site that was OK to be flooded by mail,
& had high availability, & it could confuse things.
How about if we added to freebsd.org:/etc/aliases :
something: hackers
Then those of us who find `hackers' an embarassment of a name could use
`something' & it'd all still be neatly tied into the main site
PS I guess we'd need a hook for majordomo too.
Julian S
>From owner-freebsd-hackers Sat Jul 8 02:57:50 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.10/8.6.6) id CAA19803
for hackers-outgoing; Sat, 8 Jul 1995 02:57:50 -0700
Received: from eikon.regent.e-technik.tu-muenchen.de (root@eikon.regent.e-technik.tu-muenchen.de [129.187.42.3])
by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id CAA19779
for <hackers@freebsd.org>; Sat, 8 Jul 1995 02:57:46 -0700
Received: from vector.eikon.e-technik.tu-muenchen.de ([129.187.142.36]) by eikon.regent.e-technik.tu-muenchen.de with SMTP id <55300>; Sat, 8 Jul 1995 11:57:32 +0200
Received: from localhost (localhost [127.0.0.1]) by vector.eikon.e-technik.tu-muenchen.de (8.6.11/8.6.9) with SMTP id LAA02807; Sat, 8 Jul 1995 11:57:14 +0200
Message-Id: <199507080957.LAA02807@vector.eikon.e-technik.tu-muenchen.de>
X-Authentication-Warning: vector.eikon.e-technik.tu-muenchen.de: Host localhost didn't use HELO protocol
To: Robert Withrow <witr@rwwa.com>
cc: hackers@freebsd.org
Subject: Re: ijppp feature request
In-reply-to: Your message of "Fri, 07 Jul 1995 16:20:21 +0200."
<199507071420.KAA12043@spooky.rwwa.com>
Date: Sat, 8 Jul 1995 11:57:13 +0200
From: "Julian Stacey <jhs@freebsd.org>" <jhs@vector.eikon.e-technik.tu-muenchen.de>
Sender: hackers-owner@freebsd.org
Precedence: bulk
> In my case, I would like to
> issue a ``finger'' command when the link goes up, to stimulate
> the other side to send me accumulated mail.
When I manually establish my slip link (OK, not quite manually,
with a shell, but manually invoked) I have appended a
date | mail jhs@my_up_link_host_name
I rely on the .forward there bouncing it back to my host,
& have just kinda hoped / assumed a new entry will kick off sendmail
to review its queues & start, .. I may be wrong, it's hope rather than
reading of sources, but works mostly
Julian S
>From owner-freebsd-hackers Sat Jul 8 04:12:49 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.10/8.6.6) id EAA09241
for hackers-outgoing; Sat, 8 Jul 1995 04:12:49 -0700
Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11])
by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id EAA08625
for <hackers@freebsd.org>; Sat, 8 Jul 1995 04:09:53 -0700
Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP
(5.67b+/DEC-Ultrix/4.3) id AA04190; Sat, 8 Jul 1995 13:09:48 +0200
Received: by sax.sax.de (8.6.12/8.6.12-s1) with UUCP
id NAA25445; Sat, 8 Jul 1995 13:08:27 +0200
Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id NAA19833; Sat, 8 Jul 1995 13:03:45 +0200
From: J Wunsch <j@uriah.heep.sax.de>
Message-Id: <199507081103.NAA19833@uriah.heep.sax.de>
Subject: Re: ijppp feature request
To: witr@rwwa.com (Robert Withrow)
Date: Sat, 8 Jul 1995 13:03:44 +0200 (MET DST)
Cc: erich@jake.lodgenet.com, hackers@freebsd.org
In-Reply-To: <199507072321.TAA12941@spooky.rwwa.com> from "Robert Withrow" at Jul 7, 95 07:21:43 pm
Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch)
X-Phone: +49-351-2012 669
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Content-Length: 681
Sender: hackers-owner@freebsd.org
Precedence: bulk
As Robert Withrow wrote:
>
> > well, there is a `/etc/ppp/ppp.linkup.sample', which sounds close to what
> > you want. dunno about the link down stuff.
> >
> > This probably belongs in `questions' too.
>
> You speak too soon. The commands allowed in the linkup script are
> limited to ppp commands. No way to execute arbitrary shell commands.
>
> That is why it was in hackers.
I've just sent a megapatch to Atsushi, implementing the "shell" (alias
"!") subcommand, and implementing job control (so you can background
it by ^Z).
--
cheers, J"org
joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)
>From owner-freebsd-hackers Sat Jul 8 04:16:39 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.10/8.6.6) id EAA10116
for hackers-outgoing; Sat, 8 Jul 1995 04:16:39 -0700
Received: from UUCP-GW.CC.UH.EDU (root@UUCP-GW.CC.UH.EDU [129.7.1.11])
by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id EAA10099
for <hackers@freebsd.org>; Sat, 8 Jul 1995 04:16:35 -0700
Received: from Taronga.COM by UUCP-GW.CC.UH.EDU with UUCP id AA10999
(5.67a/IDA-1.5 for freebsd.org!hackers); Sat, 8 Jul 1995 06:08:14 -0500
Received: by bonkers.taronga.com (smail2.5p) id AA03533; 8 Jul 95 06:07:31 CDT (Sat)
Received: (from peter@localhost) by bonkers.taronga.com (8.6.11/8.6.6) id GAA03530; Sat, 8 Jul 1995 06:07:30 -0500
Date: Sat, 8 Jul 1995 06:07:30 -0500
From: Peter da Silva <peter@bonkers.taronga.com>
Message-Id: <199507081107.GAA03530@bonkers.taronga.com>
To: hackers@freebsd.org
Subject: Re: Proposal to change name of this list to a less embarrassing one
Newsgroups: taronga.freebsd.hackers
In-Reply-To: <Pine.BSF.3.91.950705094058.9885A-100000@misery.sdf.com>
Organization: Taronga Park BBS
Sender: hackers-owner@freebsd.org
Precedence: bulk
In article <Pine.BSF.3.91.950705094058.9885A-100000@misery.sdf.com> you write:
> I think part of the problem, is that far too much stuff that is in
>"hackers" should actually be in "questions". For example: installation
>problems.
Changing the name to "developers" would help resolve that problem, wouldn't
it? To a lot of people "hackers" implies "hobbyists" which would cover most
FreeBSD users.
>From owner-freebsd-hackers Sat Jul 8 06:26:44 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.10/8.6.6) id GAA13730
for hackers-outgoing; Sat, 8 Jul 1995 06:26:44 -0700
Received: from itp.ac.ru (itp.ac.ru [193.233.32.4])
by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id GAA13659
for <hackers@freebsd.org>; Sat, 8 Jul 1995 06:26:27 -0700
Received: (sakr@localhost) by itp.ac.ru (8.6.11/8.6.5) id RAA18378 for hackers@freebsd.org; Sat, 8 Jul 1995 17:26:22 +0400
Date: Sat, 8 Jul 1995 17:26:22 +0400
From: "Serge A. Krashakov" <sakr@itp.ac.ru>
Message-Id: <199507081326.RAA18378@itp.ac.ru>
To: hackers@freebsd.org
Subject: ram-speed test
Sender: hackers-owner@freebsd.org
Precedence: bulk
Daer All!
Today I have read in old mailing list archive about some memory benchmark
- "ram-speed.c".
Could someone write me where I may get it. I would like to test
all computers in our Institute.
Sincerely yours, Serge Krashakov
>From owner-freebsd-hackers Sat Jul 8 06:39:51 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.10/8.6.6) id GAA20590
for hackers-outgoing; Sat, 8 Jul 1995 06:39:51 -0700
Received: from mpp.minn.net ([204.157.201.242])
by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id GAA20361
for <hackers@freebsd.org>; Sat, 8 Jul 1995 06:39:32 -0700
Received: (from mpp@localhost) by mpp.minn.net (8.6.11/8.6.9) id IAA05416; Sat, 8 Jul 1995 08:36:46 -0500
From: Mike Pritchard <mpp@legarto.minn.net>
Message-Id: <199507081336.IAA05416@mpp.minn.net>
Subject: Re: Proposal to change name of this list to a less embarrassing one
To: jhs@vector.eikon.e-technik.tu-muenchen.de (Julian Stacey)
Date: Sat, 8 Jul 1995 08:36:45 -0500 (CDT)
Cc: dufault@hda.com, hackers@freebsd.org
In-Reply-To: <199507060852.KAA02604@vector.eikon.e-technik.tu-muenchen.de> from "Julian Stacey" at Jul 6, 95 10:52:03 am
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1251
Sender: hackers-owner@freebsd.org
Precedence: bulk
> - there's a Hackers Handbook,
> `Hacker' is an un-necessary liability to our fine Op System.
>
> I guess people in the business of providing Unix like OSs to students &
> motivated individuals don't encounter much resistance, but I'm trying to
> venture into new markets, where the people are less `op. system literate';
> here the word `Hacker' is a superfluous danger signal.
I don't really care what the group is called, but I thought I would
pass on something I just saw recently in comp.lang.c. Some guy
in there was ranting about how "hackers" produce bad code, and
went on to list various C constructs that hackers use that
are bad. He had some good examples of bad programming practices,
but I would simply say that the person using them was a poor
programmer, not a "hacker".
The Hackers Handbook is a good example of something some of the
less technical types may see/hear about and cause them to
have a less than a warm fuzzy feeling about the operating system.
I always try to point out the correct word to people when they
misuse "hacker" to describe people breaking into systems.
Get it right and call them a criminal.
--
Mike Pritchard
mpp@legarto.minn.net
"Go that way. Really fast. If something gets in your way, turn"
>From owner-freebsd-hackers Sat Jul 8 07:06:56 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.10/8.6.6) id HAA05570
for hackers-outgoing; Sat, 8 Jul 1995 07:06:56 -0700
Received: from prosun.first.gmd.de (prosun.first.gmd.de [192.35.150.136])
by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id HAA05548
for <hackers@freebsd.org>; Sat, 8 Jul 1995 07:06:52 -0700
Received: from freebsd.first.gmd.de by prosun.first.gmd.de (4.1/SMI-4.1)
id AA17174; Sat, 8 Jul 95 16:06:47 +0200
Received: by freebsd.first.gmd.de (RAA01612); Sat, 8 Jul 1995 17:11:07 +0200
From: Andreas Schulz <ats@freebsd.first.gmd.de>
Message-Id: <199507081511.RAA01612@freebsd.first.gmd.de>
Subject: Re: if_ep driver
To: PowerTrip@aol.com
Date: Sat, 8 Jul 1995 17:11:07 +0159 (MET DST)
Cc: ken@rflab1.gtri.gatech.edu, hackers@freebsd.org
In-Reply-To: <950707182732_110116062@aol.com> from "PowerTrip@aol.com" at Jul 7, 95 06:27:33 pm
X-Mailer: ELM [version 2.4 PL24]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 355
Sender: hackers-owner@freebsd.org
Precedence: bulk
> hmm...509...EISA? or is that the 579?
The 509 and 509B are ISA cards. The 579 is the EISA card
and the 590 and 595 are the PCI cards ( 10 and 100Mb ).
ATS ( ats@first.gmd.de or ats@cs.tu-berlin.de )
Andreas Schulz GMD-FIRST 12489 Berlin-Adlershof Rudower Chaussee 5
Gebaeude 13.10 Tel: +49-30-6392-1856/+49-177-2134745 Germany/Europe
>From owner-freebsd-hackers Sat Jul 8 10:09:14 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.10/8.6.6) id KAA19191
for hackers-outgoing; Sat, 8 Jul 1995 10:09:14 -0700
Received: from system1.indecent.com (root@system1.indecent.com [204.95.227.58])
by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id KAA19162
for <freebsd-hackers@freefall.cdrom.com>; Sat, 8 Jul 1995 10:09:07 -0700
Received: from port26.gateway2.ic.net (port26.gateway2.ic.net [152.160.14.26]) by system1.indecent.com (8.6.11/8.6.9) with SMTP id MAA03434 for <freebsd-hackers@freefall.cdrom.com>; Sat, 8 Jul 1995 12:09:26 -0500
Date: Sat, 8 Jul 1995 13:08:12 -0400 (EDT)
From: Rob Misiak <rob@indecent.com>
X-Sender: rob@port26.gateway2.ic.net
To: freebsd-hackers@freefall.cdrom.com
Subject: Broken cc/gcc
Message-ID: <Pine.BSF.3.91.950708125532.6604A-100000@port26.gateway2.ic.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: hackers-owner@FreeBSD.org
Precedence: bulk
I have the latest 2.0.5 snapshot. Whenever I try to compile something
(with cc or gcc) I get errors like:
/usr/lib/crt0.o: Undefined symbol `__getenv' referenced from text segment
(usually 5 or more of these type of errors at a time.) When I compile
with the -static command-line option, I get less errors, and very simple
('hello world'-class) programs will compile. Does anyone know what the
problem is and how to fix it? Thanks in advance. :-)
Rob
>From owner-freebsd-hackers Sat Jul 8 11:16:58 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.10/8.6.6) id LAA28422
for hackers-outgoing; Sat, 8 Jul 1995 11:16:58 -0700
Received: from kitten.mcs.com (Kitten.mcs.com [192.160.127.90])
by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id LAA28405
for <freebsd-hackers@freebsd.org>; Sat, 8 Jul 1995 11:16:57 -0700
Received: from mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by kitten.mcs.com (8.6.10/8.6.9) with SMTP id NAA14572 for <freebsd-hackers@freebsd.org>; Sat, 8 Jul 1995 13:16:55 -0500
Received: by mailbox.mcs.com (/\==/\ Smail3.1.28.1 #28.5)
id <m0sUeQw-000k9OC@mailbox.mcs.com>; Sat, 8 Jul 95 13:16 CDT
Received: by venus.mcs.com (/\==/\ Smail3.1.28.1 #28.5)
id <m0sUeQw-000IDPC@venus.mcs.com>; Sat, 8 Jul 95 13:16 CDT
Message-Id: <m0sUeQw-000IDPC@venus.mcs.com>
Subject: Disk hang still there
To: freebsd-hackers@freebsd.org
Date: Sat, 8 Jul 1995 13:16:53 -0500 (CDT)
From: "Karl Denninger, MCSNet" <karl@mcs.com>
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Content-Length: 541
Sender: hackers-owner@freebsd.org
Precedence: bulk
2.0.5-Release, still got the disk hang problem.
Thought it was fixed with tagged queueing enabled, but it came back.
Any patches or new drivers out there?
--
--
Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity
Modem: [+1 312 248-0900] | (shell, PPP, SLIP, leased) in Chicagoland
Voice: [+1 312 248-8649] | 7 Chicagoland POPs, ISDN, 28.8, much more
Fax: [+1 312 248-9865] | Email to "info@mcs.net" WWW: http://www.mcs.net
ISDN - Get it here TODAY! | Home of Chicago's only FULL AP Clarinet feed!
>From owner-freebsd-hackers Sat Jul 8 12:14:53 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.10/8.6.6) id MAA02045
for hackers-outgoing; Sat, 8 Jul 1995 12:14:53 -0700
Received: from mpp.minn.net ([204.157.201.242])
by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id MAA02014
for <hackers@freebsd.org>; Sat, 8 Jul 1995 12:14:50 -0700
Received: (from mpp@localhost) by mpp.minn.net (8.6.11/8.6.9) id OAA08005 for hackers@freebsd.org; Sat, 8 Jul 1995 14:14:53 -0500
From: Mike Pritchard <mpp@legarto.minn.net>
Message-Id: <199507081914.OAA08005@mpp.minn.net>
Subject: Some mailing lists broken?
To: hackers@freebsd.org
Date: Sat, 8 Jul 1995 14:14:52 -0500 (CDT)
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 716
Sender: hackers-owner@freebsd.org
Precedence: bulk
I think some of the mailing lists are broken again - "bugs" in particular.
I haven't seen anything from that list in about a day (and I know
there is stuff in there - I just checked the archive on freefall, plus
I sent something to it earlier). The mail queue isn't backed up,
since there isn't anything in it waiting to be sent to me from
any of the lists.
Checking out the maillog looks like bulk_mailer is getting a
"cannot open input" error. Could this be because
/home/mail/lists/freebsd-bugs is mode 0640 and not 0644 like
hackers & the other lists that are working?
Can someone go check this out?
--
Mike Pritchard
mpp@legarto.minn.net
"Go that way. Really fast. If something gets in your way, turn"
>From owner-freebsd-hackers Sat Jul 8 14:06:27 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.10/8.6.6) id OAA23343
for hackers-outgoing; Sat, 8 Jul 1995 14:06:27 -0700
Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22])
by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id OAA23328
for <hackers@freebsd.org>; Sat, 8 Jul 1995 14:06:26 -0700
Received: from muggsy.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/24Feb95)
id AA17944; Sat, 8 Jul 95 14:00:27 -0700
Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP
id AA28035; Sat, 8 Jul 1995 17:00:25 -0400
Received: from localhost (localhost [127.0.0.1]) by whydos.lkg.dec.com (8.6.11/8.6.9) with SMTP id RAA06452; Sat, 8 Jul 1995 17:00:59 GMT
Message-Id: <199507081700.RAA06452@whydos.lkg.dec.com>
X-Authentication-Warning: whydos.lkg.dec.com: Host localhost didn't use HELO protocol
To: Julian Howard Stacey <jhs@vector.eikon.e-technik.tu-muenchen.de>
Cc: hackers@freebsd.org, n1epo4tl@ibmmail.com
Subject: Re: token ring anyone
In-Reply-To: Your message of "Thu, 06 Jul 1995 16:35:57 +0200."
<199507061435.QAA03684@vector.eikon.e-technik.tu-muenchen.de>
X-Mailer: exmh version 1.5omega 10/6/94
Date: Sat, 08 Jul 1995 17:00:51 +0000
From: Matt Thomas <matt@lkg.dec.com>
Sender: hackers-owner@freebsd.org
Precedence: bulk
> a couple of weeks ago I asked (on behalf of n1epo4tl@ibmmail.com Stuart
> Arnold) if anyone knew of any support for token ring cards with FreeBSD,
> we heard nothing ... either there's no interest or maybe it was mail
> failure ?
Token Ring is a proverbial pain in the ass.
Unlike writing a new Ethernet driver, Token Ring also involves writing
the Token Ring support code, modifying IP Multicast to work over Token
Ring (ie. map to the right funtional address), and, worst of all,
modifying ARP so that it understand how to do source routing.
Of course this ignores the fact that you really want fairly generic source
routing so you could use it with IPX or OSI or whatever else is around.
The major Token Ring chipsets are fairly painful. It also means that
the driver writer have the infrastructure to test the driver (unlike
Ethernet where you can plug two systems back-to-back or use some ThinWire
Token Ring requires a MAU). If you don't need to test source routing,
thin a single ring will be fine otherwise you'll need a bridge. You also
need a router to make sure you are dealing with stupidity of bit-flipped
ARP address properly.
Instead of writing token ring drivers, I think it would be a far better
investment to write NDIS3 miniport wrapper code for FreeBSD but I digress.
So in essence, until the pain of not having Token Ring exceeds the pain
threshold of implementation it's unlikely to be done.
That's my take on it.
Matt Thomas Internet: matt@lkg.dec.com
3am Software Foundry WWW URL: <currently homeless>
Westford, MA Disclaimer: Digital disavows all knowledge
of this message
>From owner-freebsd-hackers Sat Jul 8 14:22:10 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.10/8.6.6) id OAA29717
for hackers-outgoing; Sat, 8 Jul 1995 14:22:10 -0700
Received: from time.cdrom.com (time.cdrom.com [192.216.222.226])
by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id OAA29690
for <hackers@freebsd.org>; Sat, 8 Jul 1995 14:22:07 -0700
Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.11/8.6.9) with SMTP id OAA19321; Sat, 8 Jul 1995 14:20:17 -0700
To: Matt Thomas <matt@lkg.dec.com>
cc: Julian Howard Stacey <jhs@vector.eikon.e-technik.tu-muenchen.de>,
hackers@freebsd.org, n1epo4tl@ibmmail.com
Subject: Re: token ring anyone
In-reply-to: Your message of "Sat, 08 Jul 1995 17:00:51 -0000."
<199507081700.RAA06452@whydos.lkg.dec.com>
Date: Sat, 08 Jul 1995 14:20:17 -0700
Message-ID: <19318.805238417@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@freebsd.org>
Sender: hackers-owner@freebsd.org
Precedence: bulk
> Instead of writing token ring drivers, I think it would be a far better
> investment to write NDIS3 miniport wrapper code for FreeBSD but I digress.
Care to elaborate? :-)
> So in essence, until the pain of not having Token Ring exceeds the pain
> threshold of implementation it's unlikely to be done.
Indeed, and the pain of not having Token Ring generally diminishes
with each passing day as more and more TR user's accept the inevitable
and bail out to Ethernet.
I'm not saying that Token Ring doesn't have its faithful adherants or
some fairly indisputable strenghs (like actually approaching
reasonable link utilization efficiency or having a spare ~5Mb/sec to
play with) but it's still just not enough to break the ethernet
barrier. So until I see someone actually in possession of an IBM or
Madge TR card *and* the hacking skills to do the rest come forward,
I'll assume that the point is entirely moot.
Jordan
>From owner-freebsd-hackers Sat Jul 8 15:00:37 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.10/8.6.6) id PAA16488
for hackers-outgoing; Sat, 8 Jul 1995 15:00:37 -0700
Received: from mail.htp.com (mail.htp.com [199.171.4.2])
by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id PAA16470
for <freebsd-hackers@freebsd.org>; Sat, 8 Jul 1995 15:00:33 -0700
Received: from et.htp.com (et.htp.com [199.171.4.228]) by mail.htp.com (8.6.5/8.6.5) with SMTP id RAA09856 for <freebsd-hackers@freebsd.org>; Sat, 8 Jul 1995 17:58:59 -0400
Date: Sat, 8 Jul 1995 17:58:59 -0400
Message-Id: <199507082158.RAA09856@mail.htp.com>
X-Sender: dennis@mail.htp.com
X-Mailer: Windows Eudora Version 2.0.3
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: freebsd-hackers@freebsd.org
From: dennis@et.htp.com (dennis)
Subject: Re: token ring anyone
Sender: hackers-owner@freebsd.org
Precedence: bulk
>> a couple of weeks ago I asked (on behalf of n1epo4tl@ibmmail.com Stuart
>> Arnold) if anyone knew of any support for token ring cards with FreeBSD,
>> we heard nothing ... either there's no interest or maybe it was mail
>> failure ?
>
>Token Ring is a proverbial pain in the ass.
>
>Of course this ignores the fact that you really want fairly generic source
>routing so you could use it with IPX or OSI or whatever else is around.
>
>The major Token Ring chipsets are fairly painful. It also means that
>the driver writer have the infrastructure to test the driver (unlike
>Ethernet where you can plug two systems back-to-back or use some ThinWire
>Token Ring requires a MAU). If you don't need to test source routing,
>thin a single ring will be fine otherwise you'll need a bridge. You also
>need a router to make sure you are dealing with stupidity of bit-flipped
>ARP address properly.
>
The pain level aside, a better reason is that token ring is dead...when was
the last time anyone heard of a NEW network installation using token ring
when ethernet was an option? Token ring today is limited to IBM's hostage
customers who simply have little use for BSD unix anyway. Anyone with a
novell network can simply stick a $30. ethernet card into their server and
wire up a FreeBSD box to it if they want to put it on their net....and I'm
not sure that anyone else using token ring much matters.
db
>From owner-freebsd-hackers Sat Jul 8 16:19:18 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.10/8.6.6) id QAA21732
for hackers-outgoing; Sat, 8 Jul 1995 16:19:18 -0700
Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33])
by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id QAA21718
for <freebsd-hackers@freebsd.org>; Sat, 8 Jul 1995 16:19:17 -0700
Received: from muggsy.lkg.dec.com by inet-gw-3.pa.dec.com (5.65/24Feb95)
id AA23343; Sat, 8 Jul 95 16:16:12 -0700
Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP
id AA29056; Sat, 8 Jul 1995 19:14:57 -0400
Received: from localhost (localhost [127.0.0.1]) by whydos.lkg.dec.com (8.6.11/8.6.9) with SMTP id TAA06917; Sat, 8 Jul 1995 19:15:32 GMT
Message-Id: <199507081915.TAA06917@whydos.lkg.dec.com>
X-Authentication-Warning: whydos.lkg.dec.com: Host localhost didn't use HELO protocol
To: dennis@et.htp.com (dennis)
Cc: freebsd-hackers@freebsd.org
Subject: Re: token ring anyone
In-Reply-To: Your message of "Sat, 08 Jul 1995 17:58:59 -0400."
<199507082158.RAA09856@mail.htp.com>
X-Mailer: exmh version 1.5omega 10/6/94
Date: Sat, 08 Jul 1995 19:15:32 +0000
From: Matt Thomas <matt@lkg.dec.com>
Sender: hackers-owner@freebsd.org
Precedence: bulk
> The pain level aside, a better reason is that token ring is dead...when was
> the last time anyone heard of a NEW network installation using token ring
> when ethernet was an option? Token ring today is limited to IBM's hostage
> customers who simply have little use for BSD unix anyway. Anyone with a
> novell network can simply stick a $30. ethernet card into their server and
> wire up a FreeBSD box to it if they want to put it on their net....and I'm
> not sure that anyone else using token ring much matters.
That's assuming they are wired for Ethernet. Sure they can stick in their
Ethernet card but they may not be able to talk to anyone. Which why HP
is targetting the folks with cat-3 token ring wiring with 100baseVG.
Token Ring is sterile but it certainly ain't dead yet.
Matt Thomas Internet: matt@lkg.dec.com
3am Software Foundry WWW URL: <currently homeless>
Westford, MA Disclaimer: Digital disavows all knowledge
of this message
>From owner-freebsd-hackers Sat Jul 8 16:27:39 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.10/8.6.6) id QAA27195
for hackers-outgoing; Sat, 8 Jul 1995 16:27:39 -0700
Received: from seagull.rtd.com (root@RTD.COM [192.195.240.142])
by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id QAA27180
for <freebsd-hackers@freefall.cdrom.com>; Sat, 8 Jul 1995 16:27:37 -0700
Received: (from dgy@localhost) by seagull.rtd.com (8.6.12/8.6.9.1) id QAA27203; Sat, 8 Jul 1995 16:26:18 -0700
From: Don Yuniskis <dgy@rtd.com>
Message-Id: <199507082326.QAA27203@seagull.rtd.com>
Subject: Re: token ring anyone
To: matt@lkg.dec.com (Matt Thomas)
Date: Sat, 8 Jul 1995 16:26:18 -0700 (MST)
Cc: freebsd-hackers@freefall.cdrom.com (FreeBSD hackers)
In-Reply-To: <199507081915.TAA06917@whydos.lkg.dec.com> from "Matt Thomas" at Jul 8, 95 07:15:32 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 974
Sender: hackers-owner@FreeBSD.org
Precedence: bulk
# > The pain level aside, a better reason is that token ring is dead...when was
# > the last time anyone heard of a NEW network installation using token ring
# > when ethernet was an option? Token ring today is limited to IBM's hostage
# > customers who simply have little use for BSD unix anyway. Anyone with a
# > novell network can simply stick a $30. ethernet card into their server and
# > wire up a FreeBSD box to it if they want to put it on their net....and I'm
# > not sure that anyone else using token ring much matters.
#
# That's assuming they are wired for Ethernet. Sure they can stick in their
# Ethernet card but they may not be able to talk to anyone. Which why HP
# is targetting the folks with cat-3 token ring wiring with 100baseVG.
#
# Token Ring is sterile but it certainly ain't dead yet.
Yeah, but (aside from FDDI), do any of the popular networks offer
the determinism of a token ring (note lowercase) implementation
(i.e. for real-time apps)?
>From owner-freebsd-hackers Sat Jul 8 16:32:03 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.10/8.6.6) id QAA28968
for hackers-outgoing; Sat, 8 Jul 1995 16:32:03 -0700
Received: from sentinel.synapse.net (sentinel.synapse.net [192.197.166.1])
by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id QAA28949
for <hackers@freebsd.org>; Sat, 8 Jul 1995 16:32:00 -0700
Received: from windchime-01.synapse.net (windchime-01.synapse.net [199.84.52.253]) by sentinel.synapse.net (8.7.Beta.9/8.7.Beta.9) with SMTP id TAA20064 for < hackers@freebsd.org>; Sat, 8 Jul 1995 19:31:48 -0400 (EDT)
Message-Id: <199507082331.TAA20064@sentinel.synapse.net>
X-Authentication-Warning: sentinel.synapse.net: Host windchime-01.synapse.net [199.84.52.253] didn't use HELO protocol
Date: Sat, 08 Jul 95 19:31:42 EDT
From: evanc@synapse.net (Evan Champion)
Reply-To: evanc@synapse.net (Evan Champion)
To: hackers@freebsd.org
Subject: Filesystems
Sender: hackers-owner@freebsd.org
Precedence: bulk
I have been thinking a bit about big disks and filesystems etc.
We have some large disks (ie: the 9 GB variety). We really like them
because you pack a lot of data in to a small amount of space, and with
only 7 devices on a SCSI-2/FAST chain, that's important to us.
The problem is that when our BSD/OS server goes down (no matter how
good a system is, things happen; the most recent was a failed SIMM),
it takes forever to go through the FS checks. Since this is a major
server, we can't really afford the down time.
I was thinking a little bit about our FreeBSD servers and how when
they go down they don't seem to spend all that long in the disk
checks. Now, maybe it is just that they also don't have these darned
9 GB disks on them, but it was just an observation that I made.
Does FreeBSD do some kind of journalling that allows quick recoveries?
Also, I noted there is a LFS filesystem. Not having the LFS
documentation around, the name sort of implies that LFS is a
journalled filesystem. I also note that it is brand new with 4.4BSD.
Does the LFS work and how good is it at quick recoveries?
We're thinking of using for a very large file server so if there is
something we can do to help on recoveries it would be greatly
appreciated by us and our users.
Evan
--
Evan Champion evanc@synapse.net * Visit our World Wide Web Server
Director, Internet Systems * at <URL:http://www.synapse.net>;
Synapse Internet *
>From owner-freebsd-hackers Sat Jul 8 16:46:39 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.10/8.6.6) id QAA07862
for hackers-outgoing; Sat, 8 Jul 1995 16:46:39 -0700
Received: from misery.sdf.com (misery.sdf.com [204.191.196.34])
by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id QAA07763
for <hackers@freebsd.org>; Sat, 8 Jul 1995 16:46:26 -0700
Received: by misery.sdf.com id <925>; Sat, 8 Jul 1995 16:50:33 +0100
Date: Sat, 8 Jul 1995 16:50:12 -0700 (PDT)
From: Tom Samplonius <tom@sdf.com>
To: Evan Champion <evanc@synapse.net>
cc: hackers@freebsd.org
Subject: Re: Filesystems
In-Reply-To: <199507082331.TAA20064@sentinel.synapse.net>
Message-ID: <Pine.BSF.3.91.950708164439.17612A-100000@misery.sdf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: hackers-owner@freebsd.org
Precedence: bulk
On Sat, 8 Jul 1995, Evan Champion wrote:
> We have some large disks (ie: the 9 GB variety). We really like them
> because you pack a lot of data in to a small amount of space, and with
> only 7 devices on a SCSI-2/FAST chain, that's important to us.
You can use multiple controllers or controllers with multiple
channels. This also provides a performance benefit.
> I was thinking a little bit about our FreeBSD servers and how when
> they go down they don't seem to spend all that long in the disk
> checks. Now, maybe it is just that they also don't have these darned
> 9 GB disks on them, but it was just an observation that I made.
Disk checks are only done after an unclean shutdown.
> Does FreeBSD do some kind of journalling that allows quick recoveries?
No. But FreeBSD's fsck implementation could be more efficient. fsck
time is also determined by the amount of data on a disk.
> Also, I noted there is a LFS filesystem. Not having the LFS
> documentation around, the name sort of implies that LFS is a
> journalled filesystem. I also note that it is brand new with 4.4BSD.
> Does the LFS work and how good is it at quick recoveries?
4.4BSD LFS is broken.
Tom
>From owner-freebsd-hackers Sat Jul 8 16:51:20 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
by freefall.cdrom.com (8.6.10/8.6.6) id QAA10337
for hackers-outgoing; Sat, 8 Jul 1995 16:51:20 -0700
Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22])
by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id QAA10321
; Sat, 8 Jul 1995 16:51:19 -0700
Received: from muggsy.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/24Feb95)
id AA27459; Sat, 8 Jul 95 16:46:55 -0700
Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP
id AA29318; Sat, 8 Jul 1995 19:46:54 -0400
Received: from localhost (localhost [127.0.0.1]) by whydos.lkg.dec.com (8.6.11/8.6.9) with SMTP id TAA07134; Sat, 8 Jul 1995 19:47:30 GMT
Message-Id: <199507081947.TAA07134@whydos.lkg.dec.com>
X-Authentication-Warning: whydos.lkg.dec.com: Host localhost didn't use HELO protocol
To: "Jordan K. Hubbard" <jkh@freebsd.org>
Cc: hackers@freebsd.org
Subject: Re: token ring anyone
In-Reply-To: Your message of "Sat, 08 Jul 1995 14:20:17 MST."
<19318.805238417@time.cdrom.com>
X-Mailer: exmh version 1.5omega 10/6/94
Date: Sat, 08 Jul 1995 19:47:29 +0000
From: Matt Thomas <matt@lkg.dec.com>
Sender: hackers-owner@freebsd.org
Precedence: bulk
> > Instead of writing token ring drivers, I think it would be a far better
> > investment to write NDIS3 miniport wrapper code for FreeBSD but I digress.
>
> Care to elaborate? :-)
At the end of this message...
> > So in essence, until the pain of not having Token Ring exceeds the pain
> > threshold of implementation it's unlikely to be done.
>
> Indeed, and the pain of not having Token Ring generally diminishes
> with each passing day as more and more TR user's accept the inevitable
> and bail out to Ethernet.
> I'm not saying that Token Ring doesn't have its faithful adherants or
> some fairly indisputable strenghs (like actually approaching
> reasonable link utilization efficiency or having a spare ~5Mb/sec to
> play with) but it's still just not enough to break the ethernet
> barrier. So until I see someone actually in possession of an IBM or
> Madge TR card *and* the hacking skills to do the rest come forward,
> I'll assume that the point is entirely moot.
I've had a Proteon 1392 hitting in my hardware pile (anyone have a
good method of storing lots of PC cards? I got 3com 3c507, 3c503,
original NE2000, Intel EtherExpress, SMC Ultra, 3 DEFPAs (2MMF, one UTP),
a DEFEA, a DE434, a SMC EtherPower, a SMC EtherPower 10/100, 2 DE435s,
2 DE500s, a DC21140 eval board, 4 DE450s, a SMC EtherPower Enhanced,
a DE436, an AHA1540B, a DE100, an original DEPCA, a DE422, a DE425,
2 DE20x, 3 or 4 DE205s. Those are scattered around my desk in a
semi-random pile) but I haven't had the masochistic urge to program it.
I have also have an 8bit IBM TR card as well.
But since the manufacturers have already spent the time to write
NDIS3 drivers for Win95, it would be more interesting to write
the NDIS3 miniport wrappers for them. It wouldn't as fast or as clean
as a native driver but it might be easier.
NDIS3 miniport drivers has a relatively small set of functions that they
can call and they are 32-bit PIC code. I've thought of taking one or
two of the miniport drivers for one of the cards that I have and seeing
if I can write the NDIS3 shell that they want. From what I've been able
to tell, the work would be about the same as writing a complex device
driver. If successful, the code could probably be used as basis for
using the Win95 SCSI miniport drivers.
Novell is taking a similar approach with UnixWare. ODI NLM module can
be "transmogrified" such that they be loaded and used under UnixWare.
There's a bit of difference in opinion on how well that works depending
on whether or not they work in Utah. :-)
It should be noted that NDIS3 is really brain-dead in some spots (what
else would you expect from Microsoft?) so performance will be not be
great but at least it'll work.
Of course that still leaves the problem of doing source routing ...
Matt Thomas Internet: matt@lkg.dec.com
3am Software Foundry WWW URL: <currently homeless>
Westford, MA Disclaimer: Digital disavows all knowledge
of this message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199507090441.VAA17956>