predictive prefetching
Kroeger's Predictive Prefetching paper: http://www.usenix.org/events/usenix01/full_papers/kroeger/kroeger_html/index.html I'm assuming a lot of people saw this talk at USENIX. These are pretty interesting results; has anyone considered working on supporting this in FreeBSD? I'm interested in doing so, please drop me a note if you have comments or ideas on the best approach. --Aaron ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
ftpd patch that saves me a lot of hassle
I got sick of (presumably) warez people probing my anonymous ftp site and
dropping all kinds of hard-to-delete trash in incoming, so I patched my
ftpd to only allow directories to start with alphanumerics. There's
probably a better solution, but this works for me so I figure'd I'd share.
Combining this with a umask that doesn't allow reading uploaded files keeps
things reasonably well in hand.
--Aaron
Index: ftpd.c
===
RCS file: /usr/cvs/src/libexec/ftpd/ftpd.c,v
retrieving revision 1.62.2.15
diff -u -r1.62.2.15 ftpd.c
--- ftpd.c 2001/12/18 18:35:55 1.62.2.15
+++ ftpd.c 2002/01/19 09:47:42
@@ -2216,6 +2216,12 @@
{
LOGCMD(mkdir, name);
+
+ if (!isalnum(*name)) {
+ reply(521, Bite me.);
+ return;
+ }
+
if (mkdir(name, 0777) 0)
perror_reply(550, name);
else
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: ftpd patch that saves me a lot of hassle
The reason I only test the first character is that lots of filenames I
actually want uploaded may have some funkiness somewhere in their midst.
With an alnum first character I can deal with trash using tab completion
and not block the files I deal with normally.
isprint() is too liberal to save me time -- one careless evening, deleting
a directory named '~' made me have to go to backups. isprint allows a great
deal of stuff i don't want to hassle with, like ~ and .
Allowing directories to start with underscore sounds reasonable to me,
though. Another idea would be mapping certain special characters to
underscore. Does anyone know if other ftpds like luke's or wu address this
issue?
I wasn't proposing this as a default inclusion, but as far as that goes: a
non-default option noted in the setting up an anonymous FTP site section
of the ftpd docs seems the most appropriate option. It's just to save
administrators of anonymous ftp sites a little headache of hidden files and
those beginning with spaces or garbage.
Lots of people will be bitten by this if they don't know about it, especially
if it applies to non-anonymous users. Why can't I upload my file? It
should probably test whether the user is anonymous.
If people actually would use such an ftpd option, I'll clean it up and
submit a new patch with doc changes.
Aaron
On Sat, Jan 19, 2002 at 01:02:24PM -0800, Michael Smith wrote:
Use isprint() on the entire string; this will give the desired result in
most cases. It should probably be optional (defaulting to on, since it's
a security measure).
What? You don't like directories named '...w^Ha^Hr^He^Hz^H^H^H' ?
I like it, but there are a few problems. What about underscore? And
will this mess up people using ftp outside the U.S.?
-Matt
Matthew Dillon
[EMAIL PROTECTED]
:I got sick of (presumably) warez people probing my anonymous ftp site and
:dropping all kinds of hard-to-delete trash in incoming, so I patched my
:ftpd to only allow directories to start with alphanumerics. There's
:probably a better solution, but this works for me so I figure'd I'd share.
:
:Combining this with a umask that doesn't allow reading uploaded files keeps
:things reasonably well in hand.
:
:--Aaron
:
:
:Index: ftpd.c
:===
:RCS file: /usr/cvs/src/libexec/ftpd/ftpd.c,v
:retrieving revision 1.62.2.15
:diff -u -r1.62.2.15 ftpd.c
:--- ftpd.c 2001/12/18 18:35:55 1.62.2.15
:+++ ftpd.c 2002/01/19 09:47:42
:@@ -2216,6 +2216,12 @@
: {
:
: LOGCMD(mkdir, name);
:+
:+ if (!isalnum(*name)) {
:+ reply(521, Bite me.);
:+ return;
:+ }
:+
: if (mkdir(name, 0777) 0)
: perror_reply(550, name);
: else
:
:To Unsubscribe: send mail to [EMAIL PROTECTED]
:with unsubscribe freebsd-hackers in the body of the message
:
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: ftpd patch that saves me a lot of hassle
On Sat, Jan 19, 2002 at 12:46:03PM -0800, Julian Elischer wrote:
if you make your incoming Write-only then they will hav elottle point in
puting stuff there..
It is already write-only, but I still get lots of directory trees created
and populated with files they cannot read.
We do this, in several places, and have a script move the incoming stuff
elsewhere at regular intervals too.
(not that I disagree with your patch but I often mode 'dot files'
e.g. .cshrc, or even CVS # files
This patch only deals with directories, but I definitely see your point.
On Sat, 19 Jan 2002, Aaron Smith wrote:
I got sick of (presumably) warez people probing my anonymous ftp site and
dropping all kinds of hard-to-delete trash in incoming, so I patched my
ftpd to only allow directories to start with alphanumerics. There's
probably a better solution, but this works for me so I figure'd I'd share.
Combining this with a umask that doesn't allow reading uploaded files keeps
things reasonably well in hand.
--Aaron
Index: ftpd.c
===
RCS file: /usr/cvs/src/libexec/ftpd/ftpd.c,v
retrieving revision 1.62.2.15
diff -u -r1.62.2.15 ftpd.c
--- ftpd.c 2001/12/18 18:35:55 1.62.2.15
+++ ftpd.c 2002/01/19 09:47:42
@@ -2216,6 +2216,12 @@
{
LOGCMD(mkdir, name);
+
+ if (!isalnum(*name)) {
+ reply(521, Bite me.);
+ return;
+ }
+
if (mkdir(name, 0777) 0)
perror_reply(550, name);
else
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
gzip's custom i386 asm should be disabled
gzip's i386 assembly code, activated by default in the FreeBSD source tree,
produces poor performance on an i686 core (PPro/P2/P3). This is due to the
'partial register stall' problem, explained in a URL recently brought up on
the list, http://www.emulators.com/pentium4.htm.
In the course of learning more about partial register stalls I came across
the following i686 and i586 assembly optimizations for gzip:
http://www.muppetlabs.com/~breadbox/software/assembly.html.
This optimized i686 asm avoids partial reg stall and is between 20-40%
faster, with higher compression levels achieving greater benefit from the
patch. The i586 patch is usually only 5% faster, but in some cases achieves
a 25% speedup.
For completeness, I also ran some tests on a non-asm gcc 2.95.2 compile,
with and without -march=pentiumpro. Here are the results (three runs,
averaged, caches warmed with some throwaway runs) on a Pentium II 400,
linux-2.4.2.tar, --best.
[type] [user secs] [time (as % of slowest)]
i386 asm:175 100%
no asm, -O:142 81.1%
no asm, -O2:139 79.4%
no asm, -O -march=pentiumpro:136 77.7%
no asm, -O2 -march=pentiumpro:140 80.0%
i686 asm:124 70.8%
I'm interested in other people's results/tests. Particularly, I should do
some runs with -mcpu=pentiumpro as well.
An important part of the equation is to make sure it doesn't hurt i586
machines. I did several tests on a Pentium 200MMX; the i386 asm and the
gcc-emitted asm are not measurably different on that CPU.
Brian Raiter ([EMAIL PROTECTED], author of the i586/i686 asm patches)
has contacted the gzip maintainers, but it's been years since a release and
there may not be another gzip release. I have seen a 1.2.4a release which
had his files in a contrib/ directory, but they were not active in any way.
Since I would imagine a large percentage of FreeBSD users run on i686
cores, it'd be great to get this pretty significant speed increase into our
tree.
The i686 patch is neat (30% faster!) but its improvement over gcc's emitted
assembly is small. Disabling the old i386 assembly seems a good first
step. Attached is a patch that disables the custom asm.
I'm interested in hearing everyone's comments.
Aaron
Index: Makefile
===
RCS file: /usr/cvs/src/gnu/usr.bin/gzip/Makefile,v
retrieving revision 1.21
diff -u -r1.21 Makefile
--- Makefile1999/08/27 23:35:48 1.21
+++ Makefile2001/03/20 23:59:48
@@ -8,11 +8,6 @@
CFLAGS+=-DSTDC_HEADERS=1 -DHAVE_UNISTD_H=1 -DDIRENT=1
GREP_LIBZ?=YES
-.if ${MACHINE_ARCH} == "i386"
-SRCS+= match.S
-CFLAGS+=-DASMV
-.endif
-
MLINKS= gzip.1 gunzip.1 gzip.1 zcat.1 gzip.1 gzcat.1
MLINKS+= zdiff.1 zcmp.1
Re: locked accounts and adduser
On Tue, Jan 18, 2000 at 05:14:26PM -0500, Ben Rosengart wrote: I thought it would be nice if one could create locked accounts with adduser. So I asked my nice Perl-hacking coworker Evan Leon to come up with a patch. Enter password []: Use an empty password or lock the password? lock no [yes]: lock ... # grep user /etc/master.passwd user:*:1001:1001::0:0:Joe User:/home/user:/bin/sh The patch is attached. Anyone like it? Any chance it could be i like this. i hope it gets committed; i would definitely use it. did any committers pick this up? Another idea I have is to allow adduser to accept a hashed password instead of a plaintext one. Perhaps if this goes over well, Evan and I will work on that next. i'd find this useful as well. aaron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
user-space filesystems
hello, i've done some searching and i've seen discussion of userland fs before. has there been any progress in the user-space filesystem area? i have a nifty project and i would like to avoid using loopback NFS; have we got anything akin to linux's userfs yet? if freebsd doesn't have this capability, where would a good place to start be on loopback NFS? maybe somebody has a loopback NFS skeleton i can start from? any pointers/discussion would be helpful. aaron here's one of the messages that made me say "yeah, like that!": Date: Sat, 17 Jul 1999 14:57:45 -0400 From: "David E. Cross" [EMAIL PROTECTED] To:[EMAIL PROTECTED] Subject: USFS (User Space File System) Message-ID: [EMAIL PROTECTED] I am looking at a project that will require a user based process to interact with the system as if it were a filesystem. The traditional way I have seen this done is as the system NFS mounting itself (ala AMD). I would really like a more clean approach to this. What I am interested in is a 'User Space File System' that would interact with a user process in a similiar manor to how nfsd's do. A process would issue a mount (ok, this is different than NFSDs), then it would make a special system call with a structure, that call would return whenever a request was pending with the structure filled in with the appropriate information. The user process would fulfill the request, pack the return data into the structure and call kernel again. I have a number of questions on more specific ideas (like caching, inode/vnode interaction, etc). But I am just feeling arround for what people think about this. Any ideas/comments? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Proposal: Add generic username for 3rd-party MTA's
this strikes me as unecessary. anybody installing a new mta can create the necessary users and name them appropriately. port maintainers have already solved this problem (see the install glue for the qmail port, which as has been mentioned creates _seven_ users.) it is not particularly hard, and the existing solution does a fine job. i have a feeling this "smtp" user would sit unused while people create qmail-* users, a 'postfix' user, etc. i'm a qmail user, i would end up ignoring this user if it were added, and it will be equally useless to the large number of people who stick with the bundled (superuser) sendmail. aaron On Wed, Sep 01, 1999 at 06:33:06PM +0200, Sheldon Hearn wrote: Hi folks, I plan to add a user ``smtp'' with UID 25 and a member of group ``mail'', for use in running non-priveledged MTA's in FreeBSD. This is primarily for the convenience of maintainers of mail ports. The last time I brought this up, my request was blown away in a flurry of arguments against incorporating other MTA's into the base system. !!! DON'T GO THERE !!! This has nothing to do with what's in the base system. This has to do with making it easier for people to run 3rd-party software, which isn't part of the base system, in a non-priveledged state. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Status of FBSD sparc porting?
there has been some discussion recently, and lots of volunteering. however, i don't think anyone has done any real work yet. i have a couple of sparcs to use for it, and several other people have sparc boxes waiting to test and contribute but no one has yet stepped up to lead the effort forward. from what i can tell the hard parts are: - pmap/mmu issues? - dealing with the different bus architecture(s) #2 is probably partially addressed by the new-bus work going on in -current which i don't know a lot about, maybe someone else can comment. both issues were tackled by net/openBSD for their sparcness, but there's enough divergence to make picking up the changes non-trivial, otherwise someone would have finished this already. however i think having the other sparc-capable BSDs as a reference will be helpful. my plan was to install openBSD on one of my sparcs and use it to compile FreeBSD code and start banging on this stuff, but i have not had enough free time to get going on it. aaron On Wed, Sep 01, 1999 at 07:14:10PM -0400, BSD Bob wrote: Hello I have been running FBSD for about 5 years, and am relatively comfortable with it on x86 machines. But, I also run several sparcs of various flavors, at home. What is the status of the FBSD Sparc port? Thanks Bob To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Proposal: Add generic username for 3rd-party MTA's
this strikes me as unecessary. anybody installing a new mta can create the necessary users and name them appropriately. port maintainers have already solved this problem (see the install glue for the qmail port, which as has been mentioned creates _seven_ users.) it is not particularly hard, and the existing solution does a fine job. i have a feeling this smtp user would sit unused while people create qmail-* users, a 'postfix' user, etc. i'm a qmail user, i would end up ignoring this user if it were added, and it will be equally useless to the large number of people who stick with the bundled (superuser) sendmail. aaron On Wed, Sep 01, 1999 at 06:33:06PM +0200, Sheldon Hearn wrote: Hi folks, I plan to add a user ``smtp'' with UID 25 and a member of group ``mail'', for use in running non-priveledged MTA's in FreeBSD. This is primarily for the convenience of maintainers of mail ports. The last time I brought this up, my request was blown away in a flurry of arguments against incorporating other MTA's into the base system. !!! DON'T GO THERE !!! This has nothing to do with what's in the base system. This has to do with making it easier for people to run 3rd-party software, which isn't part of the base system, in a non-priveledged state. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Status of FBSD sparc porting?
there has been some discussion recently, and lots of volunteering. however, i don't think anyone has done any real work yet. i have a couple of sparcs to use for it, and several other people have sparc boxes waiting to test and contribute but no one has yet stepped up to lead the effort forward. from what i can tell the hard parts are: - pmap/mmu issues? - dealing with the different bus architecture(s) #2 is probably partially addressed by the new-bus work going on in -current which i don't know a lot about, maybe someone else can comment. both issues were tackled by net/openBSD for their sparcness, but there's enough divergence to make picking up the changes non-trivial, otherwise someone would have finished this already. however i think having the other sparc-capable BSDs as a reference will be helpful. my plan was to install openBSD on one of my sparcs and use it to compile FreeBSD code and start banging on this stuff, but i have not had enough free time to get going on it. aaron On Wed, Sep 01, 1999 at 07:14:10PM -0400, BSD Bob wrote: Hello I have been running FBSD for about 5 years, and am relatively comfortable with it on x86 machines. But, I also run several sparcs of various flavors, at home. What is the status of the FBSD Sparc port? Thanks Bob To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: New tests for test(1)
this seems undesirable to me, since using it immediately makes your shell scripts nonportable. i liked the ls -t suggestion though. -- Aaron Smith [EMAIL PROTECTED] On Thu, Aug 12, 1999 at 11:18:50AM +0200, Graham Wheeler wrote: thinking - wouldn't it be a good idea to add some new tests to test(1), to compare files based on criteria like size or modification date? Anyone else think this is a good idea? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: New tests for test(1)
this seems undesirable to me, since using it immediately makes your shell scripts nonportable. i liked the ls -t suggestion though. -- Aaron Smith aa...@mutex.org On Thu, Aug 12, 1999 at 11:18:50AM +0200, Graham Wheeler wrote: thinking - wouldn't it be a good idea to add some new tests to test(1), to compare files based on criteria like size or modification date? Anyone else think this is a good idea? To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Inetd and wrapping.
On Sun, 27 Jun 1999 22:26:34 EDT, John Baldwin writes: Let's say I have two services, foo and bar, with food and bard. I want to wrap food, but *NOT* bard and they are both in /etc/inetd.conf. How do you propose to solve this with the internal wrapping (which is a good idea, IMO as it eliminates an exec())? i wouldn't...i'd have to either pay the (small) cost of wrapping or pay the (less small) tcpd exec and not use internal wrapping. it's "nice" to save the exec, but intensely performance or latency sensitive daemons probably shouldn't be starting out of inetd, they should be standalone and preforked or threaded... aaron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Inetd and wrapping.
On Sun, 27 Jun 1999 22:26:34 EDT, John Baldwin writes: Let's say I have two services, foo and bar, with food and bard. I want to wrap food, but *NOT* bard and they are both in /etc/inetd.conf. How do you propose to solve this with the internal wrapping (which is a good idea, IMO as it eliminates an exec())? i wouldn't...i'd have to either pay the (small) cost of wrapping or pay the (less small) tcpd exec and not use internal wrapping. it's nice to save the exec, but intensely performance or latency sensitive daemons probably shouldn't be starting out of inetd, they should be standalone and preforked or threaded... aaron To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
ufs/ffs resize?
anybody done any work on a utility for growing ufs filesystems? aaron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Inetd and wrapping.
On Fri, 25 Jun 1999 10:14:48 +0200, Sheldon Hearn writes: I think I prefer the suggestion I saw from someone else, which would allow ftpstream tcp nowait/10/10/wrap root ... This can be done in such a way as to be backward compatible. Looks like something for the week-end, if I can convince my wife that it's a good idea. :-) could you please restate the argument for this? i still haven't heard a decent reason for this sort of conf format perturbation. every small whack like this makes freebsd weirder to administrate -- there is a value to sharing the same inetd.conf format with lots of other platforms. if people have their undies in a wad over this, can't they compile inetd without LIBWRAP? aaron To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Inetd and wrapping.
On Fri, 25 Jun 1999 16:05:05 +0200, Sheldon Hearn writes: We'll also end up with an inetd that _can_ wrap if it's told to (-w and -ww). So we end up offering a better super-server than we had before, with no backward compatibility problems, and no additional incompatibilities with other systems (I can't find an inetd that uses the -w flag for anything). hi sheldon, i have no problem with -w options, but i am still surprised that you want to go ahead with the conf format change. i'm going to present my rebuttal here, but the only argument i could dig up was there is missing functionality. (john baldwin? not sure) raised the issue that before, he could control which services were wrapped. now, all services are wrapped. why is this bad? what has been lost? can the user no longer get the old behavior? no, he can. undefining LIBWRAP at compile time (or a runtime flag) plus tcpd gets him exactly where he was before. this will be even less of an issue with -w flags or an inverted default. performance incurred by reading default allow rules on invocations? no, for several reasons. the hosts.allow file is going to be in the cache. the design is first matched, so one can also place the service one is concerned about at the beginning of the lists. but third and most importantly: if startup performance is an issue to the extent that the small overhead of this call is important, you should not be using inetd. you should have a standalone daemon. (which you can decide to wrap or not wrap). the overhead here is going to in reality be small. logging configurability? i seem to remember something about this, and while i am trying to come up with a difference, i can't see one. hosts.allow is very configurable logging wise. the messages come from inetd, yes...but they can be separated out by severity/facility. i can't imagine logging differences is a good reason. so to this one too i have to say no. we already have a service-by-service control file hosts.allow that provides the ability to in EFFECT control what gets wrapped. please do not duplicate that functionality again -- we can do without it. it's an additional complexity that buys us *nothing*. The additional option in inetd.conf is not something I want. However, it's something someone has made a legitimate public argument for, to which I can't come up with a decent rebuttal. i hope i've made a persuasive case that a *conf file format change* isn't justified here. it doesn't make sense, especially if you are, as you have mentioned, going to switch unwrapped to default and require -w for wrapping. thanks, aaron To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Inetd and wrapping.
On Fri, 25 Jun 1999 20:12:01 BST, David Malone writes: This isn't so much a conf format change, as a conf format extension. It is the same type of extension as was added to support max child and max child per minute - which aren't a standard inetd feature. All old inetd.conf files remain valid. hey, that's a pretty neat feature. i confess i wasn't aware of that. out of curiosity, can old inetds read this without choking? (sheldon said backwards compatible the other day but i'm not sure if he meant upwards compatible...) (It's not like inetd.conf is all that machine independant anyway, as it is full of paths to programs and contains services specific to that machine. You'd never condider rdisting it between machines of a different architecture for example). agreed; what i was trying to get at is the mental difference in dealing with it. i didn't realize there was an extension already in place -- i should have checked the man page over when i saw sheldon's first message about wait/10/10/nowrap. in order to make this compatible won't one have to specify the not-so-pretty wait/0/0/nowrap? i guess wait/nowrap could be made to work. that's less ugly. is 0 already an alias for unlimited? i am less bothered by this change given the maxchild precedent, if there are definitely people who will *use* this. if people don't actually use it, it will just become a chunk of legacy extra-complexity. Some people think that doing the hosts.allow lookup is too expensive for some services but not others. (It requires opening /etc/hosts.allow, reading it in line by line and possibly doing DNS lookups). you won't have to go to disk, though (it will be cached for all cases in which you care), and if you've got an early allow rule for the service, you won't have to do any lookups. and like you say, if it's that sensitive, why is it starting out of inetd? all: sorry if i came off too strident. i have a sore spot for feeping creaturism. :) aaron To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
ufs/ffs resize?
anybody done any work on a utility for growing ufs filesystems? aaron To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
synch primitives (was Re: Microsoft performance)
On Thu, 24 Jun 1999 20:14:19 CDT, Alfred Perlstein writes: I'm not sure what you mean by the refernce to malloc types, I just thought something along the lines of mutex_t with an API for trying, allocating, freeing and initializing them. i'd really like to implement some of the basic solaris primitives: mutex, cv (condition variable), sema p/v. i sent a message to the smp list on this at one point but didn't get much of a response other than cranky noises about super fine-grained locking isn't worth it. what i'd like to see is the groundwork laid for finER locking so that we can gradually break up the points of contention. mutex/cv/sema are intuitive and taught in every OS course; i don't feel simple_lock or lockmgr are desirable or adequate. i'm willing to work on it, but i can't get to it for at least a couple of months, so i'm hoping someone else wants to work on it too. aaron To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Serial Console Wierdness
'cu' hangs up really easily. use 'kermit' (it's in ports) and the hangup problem will disappear. i tried to find an option to cu to modify its hangup behavior but to no avail. your second problem sounds like it could be terminal sizing -- have you tried this with a default 80x24 window, set and exported TERM properly, etc? i was not able to get my console to work properly past 38400 baud; i am not sure why. 38400 has been just fine speed-wise for me, though, so i'm not that upset. :) (also see http://www.arctic.org/~aaron/tips/freebsd-serial-console) aaron On Tue, 22 Jun 1999 13:31:33 EDT, Bill G. writes: I got a serial console working on COM2, to which I have connected another FreeBSD box. I connect with 'cu' fine, but I'm running into a couple of problems which I haven't been able to find and answer for. o When I connect, when the machine is first turned on, I get disconnected twice during the boot up sequence (cu reports Got hangup signal) -- looks like when the sio1 device is probed, and also when getty runs. o 9600 was rather slow, so I changed it to 115200, which worked, however I had a few problems with terminal display -- any output that scrolls down past the bottom of the screen gets 'garbled'. (IE, I run clear; ls -l / -- the first 23 lines look ok then it gets messed up). Same results from console mode of my client machine and from an xterm. I thought that 115200 might be too fast, so I slowed it down to 38400, but same trouble. I'm not sure if this occured at 9600. Any thoughts / ideas / suggestions would be appreciated. Thanks, To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
inetd/tcpd...changing hosts.allow...plus a documentation issue
hi all, [this is all on 3.2-RELEASE] i recently had some problems getting inetd tcp wrappers to do the right thing. i tried a sample configuration where i allowed telnet explicitly: ALL : localhost : allow telnetd : ALL : allow ALL : ALL : deny unfortunately incoming telnet was still denied. at first i tried HUPping inetd to reread the hosts.allow, but after looking at the source it appears to re-read its information each time hosts_access is called. has anyone else had problems updating this file and getting inetd to reflect the new behavior? note that tcpdmatch telnetd client_host was reporting access granted and yet inetd was refusing the connection. killing inetd COMPLETELY and restarting inetd caused it to start accepting the connections. i'm looking at it a bit but perhaps a maintainer knows if something is being cached here? on another note, LIBWRAP_INTERNAL looks like it must be defined for internal services to be wrapped, yet it is not defined during freebsd's compile -- only LIBWRAP is. yet freebsd's inetd man page says that internal services may be wrapped. since it is not currently so by default, perhaps either the documentation or the Makefile should be modified? aaron To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Changing Bootmgr display
On Sat, 19 Jun 1999 14:26:52 EDT, John Baldwin writes: Then don't use BootEasy. The OS-BS boot manager is quite nice, and the beta version (which seems very stable in my experience) even provides a nice colorful menu on boot up as well as a nice installation utility. And with that you can name each partition whatever you want, put them in any order, and optionally have a default partition to boot to. LILO's an option too, right? Is no one mentioning it for some incompatibility I don't know about (I haven't used it with FreeBSD), or is the reason political? Aaron To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: High syscall overhead?
On 11 Jun 1999 23:15:15 PDT, Arun Sharma writes: Can someone explain to me why is SYSCALL_LOCK necessary ? It certainly seems to hurt system call performance on a MP machine. Also, is there any data on lock contention in FreeBSD ? Is anyone working on decomposing some of the giant locks ? I have a follow-on question: is there any planned work to give FreeBSD some of the basic synch primitives? I would love to help finer-grain the kernel, (having just today built my first SMP FreeBSD system), but first I think I'd need to implement mutexes and condition variables. It looks like there may be spin/sleeplocks and rwlocks, but they're not called that. Is there any work being done in this area? I think implementing the SVR4 synch primitives (mutex, condvars, maybe semas, rwlocks) would be great, since that's what's taught, and they're intuitive. I'm still trying to figure out the deal with lockmgr. -- Aaron Smith VERITAS Software File System EngineerI'll call him mini me. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
