date:20010129


At 02:01 29/01/01 -0500, Garance A Drosihn wrote:
Mouss [EMAIL PROTECTED] mentioned that NetBSD has a closeall
function in it's libc, and it sounded like he was going to
mimic that instead of the fcntl change.  If I were going to
mimic something, I'd rather mimic netbsd than some feature
which exists only in AIX.  And as I mentioned in my previous
message, I think the AIX strategy warps the definition of
the fcntl routine, so I was not too fond of it even if there
hadn't been any BSD-based alternative to follow.
--

I fully agree that we'd better mimic netbsd than aix...
but the netbsd closeall() is just a libc function that calls close()
for all descriptors. so we can still mimic it with:

#define closeall(start) fcntl(start, F_CLOSEM, 0)

and with this, we have both netbsd and aix compat. note that if I
do it for freebsd, I'll do the same for netbsd and openbsd (I'm a fan of
*BSD convergence [I don't mean they should be the same, but unjustified
diffs should be killed whenever possible]:).

As for the "generic" syscall mechanism, I'd love it. I think that there are 
many places
where "names" would be good, instead of hardcoded numbers. The only problem is
to find a way to do that without reducing performance. names are good. just 
try to see
what it would be if filenames were replaced by inodes. I think that having 
a name-based
mechanism makes it easier to add new syscalls or reject deprecated ones.

Now this is not restricted to syscalls. there are other places. for 
examaple, we could have
device names that are "user" configurable, instead of the ef0, npx0, and 
the like.
for network interfaces, I'd suggest adding a field "title" so that one can do:
# ifconfig external
instead of something like "ifconfig fxp0".
While this is of limited use in ifconfig (the guy who uses ifconfig should 
know what he is doing),
this would be useful when configuring firewalls and the like. Indeed, it 
means a thing to block some
packets received by "external" interface than by "ef0". While the guy might 
change the interface and
replace an ef0 with a xl1, the "external" concept is still the same.

back to the closeall, here is what I suggest:
- add the fcntl option. the coherence arg is certainly reasonable, but 
fcntl is not a "cohrent" function
(thanks to svr4 lobbying into posix:).
- add a closeall macro to call it.

this gives both aix and netbsd compat (and if the fcntl thing goes into 
netbsd, the compat would be full).


cheers,
mouss



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: [kernel patch] fcntl(...) to close many descriptors


At 10:37 28/01/01 -0800, Luigi Rizzo wrote:


 generic_syscall("fdcloseall", );

In this way it would be clear what the non-portable pieces of code
are, and the mechanism would be extensible with no changes to
libraries and syscalls. You could even have dynamically-loaded
modules implementing new "syscalls".

I see a meachanism like
 new_syscall(str, args) = syscall(hash(str), args)
where hash() is chosen to guarantee unicity (that wouldn't be hard to find).
we then have both performance (working with indexes instead of comparing
strings) like what is currently available, and the flexibility of strings.

Note that this goes in the same dynamic "wind" than loadable modules and
the like: static gets old...


cheers,
mouss



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: [kernel patch] fcntl(...) to close many descriptors

2001-01-29 Thread Jacques A. Vidrine


On Mon, Jan 29, 2001 at 03:13:05PM +0100, mouss wrote:
 I fully agree that we'd better mimic netbsd than aix...
 but the netbsd closeall() is just a libc function that calls close()
 for all descriptors. so we can still mimic it with:
 
 #define closeall(start) fcntl(start, F_CLOSEM, 0)

Better a function than a macro.

 and with this, we have both netbsd and aix compat. note that if I
 do it for freebsd, I'll do the same for netbsd and openbsd (I'm a fan of
 *BSD convergence [I don't mean they should be the same, but unjustified
 diffs should be killed whenever possible]:).
 
 As for the "generic" syscall mechanism, I'd love it. I think that
 there are many places where "names" would be good, instead of
 hardcoded numbers. The only problem is to find a way to do that
 without reducing performance. names are good. just try to see what it
 would be if filenames were replaced by inodes. I think that having a
 name-based mechanism makes it easier to add new syscalls or reject
 deprecated ones.

Performance is not much of an issue.  A perfect hash can be generated
for syscall names.

[snip]
 back to the closeall, here is what I suggest:
 - add the fcntl option. the coherence arg is certainly reasonable, but 
 fcntl is not a "cohrent" function
 (thanks to svr4 lobbying into posix:).
 - add a closeall macro to call it.
 
 this gives both aix and netbsd compat (and if the fcntl thing goes into 
 netbsd, the compat would be full).

I really do not care for using fcntl with this.  fcntl operates on a 
single file descriptor -- F_CLOSEM mucks up the interface.

-- 
Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: [kernel patch] fcntl(...) to close many descriptors

2001-01-29 Thread Daniel Eischen


On Mon, 29 Jan 2001, Jacques A. Vidrine wrote:
 On Mon, Jan 29, 2001 at 03:13:05PM +0100, mouss wrote:
  I fully agree that we'd better mimic netbsd than aix...
  but the netbsd closeall() is just a libc function that calls close()
  for all descriptors. so we can still mimic it with:
  
  #define closeall(start) fcntl(start, F_CLOSEM, 0)
 
 Better a function than a macro.

I agree.

  and with this, we have both netbsd and aix compat. note that if I
  do it for freebsd, I'll do the same for netbsd and openbsd (I'm a fan of
  *BSD convergence [I don't mean they should be the same, but unjustified
  diffs should be killed whenever possible]:).
  
  As for the "generic" syscall mechanism, I'd love it. I think that
  there are many places where "names" would be good, instead of
  hardcoded numbers. The only problem is to find a way to do that
  without reducing performance. names are good. just try to see what it
  would be if filenames were replaced by inodes. I think that having a
  name-based mechanism makes it easier to add new syscalls or reject
  deprecated ones.
 
 Performance is not much of an issue.  A perfect hash can be generated
 for syscall names.
 
 [snip]
  back to the closeall, here is what I suggest:
  - add the fcntl option. the coherence arg is certainly reasonable, but 
  fcntl is not a "cohrent" function
  (thanks to svr4 lobbying into posix:).
  - add a closeall macro to call it.
  
  this gives both aix and netbsd compat (and if the fcntl thing goes into 
  netbsd, the compat would be full).
 
 I really do not care for using fcntl with this.  fcntl operates on a 
 single file descriptor -- F_CLOSEM mucks up the interface.

Please don't forget libc_r and what it has to do when opening and
closing files.  Also, close(2) is a cancellation point.  I'd expect
closeall(2/3) would also be a cancellation point even if not spelled
out in POSIX (since it doesn't exist).

-- 
Dan Eischen


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Snowhite and the Seven Dwarfs - The REAL story!

2001-01-29 Thread Ronald G Minnich


On Mon, 29 Jan 2001, Hahaha wrote:

 Today, Snowhite was turning 18. The 7 Dwarfs always where very educated and
 polite with Snowhite. When they go out work at mornign, they promissed a
 *huge* surprise. Snowhite was anxious. Suddlently, the door open, and the Seven
 Dwarfs enter...





To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Snowhite and the Seven Dwarfs - The REAL story!

2001-01-29 Thread Ronald G Minnich


On Mon, 29 Jan 2001, Ronald G Minnich wrote:

 On Mon, 29 Jan 2001, Hahaha wrote:

  Today, Snowhite was turning 18. The 7 Dwarfs always where very educated and
  polite with Snowhite. When they go out work at mornign, they promissed a
  *huge* surprise. Snowhite was anxious. Suddlently, the door open, and the Seven
  Dwarfs enter...


uh, sorry about that last stupid email thing I just sent somehow. I'm not
even sure what I did. Time for coffee.

ron



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

No Subject

2001-01-29 Thread Aaron


Hello,
  I have FreeBSD 4-STABLE running a binary install of XFree86 4.0.2. 
After installing xine from sources, I get a message saying I dont have 
Thread-safe X libraries and it wont run. I've scoured google and many 
newsgroups in search of anything on getting these "thread safe" libraries.
  Can anyone point me in the right direction as to how to obtain these 
files, and add them or make sure they are added, for XFree86 4.0.2 
binary. I'm not too keen on compiling the whole thing...

  As always, I tried to do my research before submitting to the 
list...last ditch effort here. I even tried XFree86's list to no avail.

Any help is greatly appriciated.

peace - click46




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: ports/x11/XFree86-4/files/patch-xthreads: broken in CURRENT?

2001-01-29 Thread Konstantin Chuguev


Aaron wrote:

 Hello,
   I have FreeBSD 4-STABLE running a binary install of XFree86 4.0.2.
 After installing xine from sources, I get a message saying I dont have
 Thread-safe X libraries and it wont run. I've scoured google and many
 newsgroups in search of anything on getting these "thread safe" libraries.
   Can anyone point me in the right direction as to how to obtain these
 files, and add them or make sure they are added, for XFree86 4.0.2
 binary. I'm not too keen on compiling the whole thing...

   As always, I tried to do my research before submitting to the
 list...last ditch effort here. I even tried XFree86's list to no avail.

 Any help is greatly appriciated.


There is a patch in the ports/x11/XFree86-4/files/patch-xthreads (of December
2000) which is supposed to turn on XTHREADS for FreeBSD. Either you'll need
to find the fresh X binary package, or to compile everything yourself.

Interesting that on my CURRENT (of 5 January 2001; ports of 26 January) this
patch breaks compilation of Xlib. Everything's fine whan it's removed. I
haven't got any messages about missing libraries yet, but maybe just because
I didn't try anything like xine...


--
  * *Konstantin Chuguev - Application Engineer
   *  *  Francis House, 112 Hills Road
 *   Cambridge CB2 1PQ, United Kingdom
 D  A  N  T  E   WWW:http://www.dante.net





To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Virus in your letter

2001-01-29 Thread Mailer-Daemon


÷ÁÛÅ ÐÉÓØÍÏ ÎÅ ÂÙÌÏ ÄÏÓÔÁ×ÌÅÎÏ ÐÏ ÎÁÚÎÁÞÅÎÉÀ.
AVP ÏÂÎÁÒÕÖÉÌ × ÎÅÍ ×ÉÒÕÓ ÉÌÉ ÔÒÏÑÎ: '/[From:  Hahaha [EMAIL PROTECTED]][Date:  
Mon, 29 Jan 2001 00:23:48 -0800 (PST)]:\joke.exe infected: I-Worm.Hybris.b
/var/spool/exim/input/T/14NGmT-0002wi-00-D/[From:  Hahaha [EMAIL PROTECTED]][Date:  
Mon, 29 Jan 2001 00:23:12 -0800 (PST)]:\sexy infected: I-Worm.Hybris.b'.
ðÒÏ×ÅÒØÔÅ Ó×ÏÊ ËÏÍÐØÀÔÅÒ !


From: [EMAIL PROTECTED] (freebsd-hackers-digest)
To: [EMAIL PROTECTED]
Subject: freebsd-hackers-digest V5 #23



http://www.chat.ru  http://www.avp.ru


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: [kernel patch] fcntl(...) to close many descriptors


hi,
i have to admit i am not too much into theory of hashing, but i am
unclear on how a perfect hash function can be simpler than "the
obvious method" when the namespace is changing dynamically because
modules are added or deleted.
(the obvious method would be a cheap hash on 2-4 chars of
the name followed by a scan of the list in each hash slot.)

Hopefully the number of functions using this method is
small enough not to worry about the depth of the lists,
and the type of calls using this method is one where the amt
of work in the syscall itself is way larger than the matching cost.

cheers
luigi

  generic_syscall("fdcloseall", );
 
 In this way it would be clear what the non-portable pieces of code
 are, and the mechanism would be extensible with no changes to
 libraries and syscalls. You could even have dynamically-loaded
 modules implementing new "syscalls".
 
 I see a meachanism like
  new_syscall(str, args) = syscall(hash(str), args)
 where hash() is chosen to guarantee unicity (that wouldn't be hard to find).
 we then have both performance (working with indexes instead of comparing
 strings) like what is currently available, and the flexibility of strings.
 
 Note that this goes in the same dynamic "wind" than loadable modules and
 the like: static gets old...
 
 
 cheers,
 mouss


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Snowhite and the Seven Dwarfs - The REAL story!

2001-01-29 Thread Pedro F. Giffuni


Definitely a virus!
Virus W95.Hybris.Gen.dr found. File NOT cleaned.

Pedro.

Patryk Zadarnowski wrote:
 
 On Mon, 29 Jan 2001 00:23:48 -0800 (PST), Hahaha [EMAIL PROTECTED] wrote:
 
  Today, Snowhite was turning 18. The 7 Dwarfs always where very educated and
  polite with Snowhite. When they go out work at mornign, they promissed a
  *huge* surprise. Snowhite was anxious. Suddlently, the door open, and the
  Seven Dwarfs enter...
 
 That must be the most amusing Windows virus I've ever seen (it is a virus,
 isn't it?).  Four spelling mistakes and five grammar problems in four lines of
 text, probably sent to millions of people.
 
 A few months ago someone suggested that all binary attachments should be
 stripped from freebsd-hackers mail. I believe it is still a very good idea,
 and patches tend to be posted as text anyway.
 
 Pat.
 
 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 Patryk ZadarnowskiUniversity of New South Wales
 [EMAIL PROTECTED] School of Computer Science and Engineering
 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with "unsubscribe freebsd-hackers" in the body of the message

begin:vcard 
n:Giffuni;Pedro
tel;fax:1 (360) 343-0501
tel;home:(412) 665 2956
tel;work:(412) 624-9862
x-mozilla-html:FALSE
url:http://www.geocities.com/giffunip/
org:University of Pittsburgh;Industrial Engineering
adr:;;5820 Elwood St. Apt. 34;Pittsburgh;PA;15232;USA
version:2.1
email;internet:[EMAIL PROTECTED]
title:Teaching Assistant
fn:Pedro F. Giffuni
end:vcard

Re: [kernel patch] fcntl(...) to close many descriptors


On Sun, 28 Jan 2001 12:45:10 -0800 (PST), Luigi Rizzo [EMAIL PROTECTED] said:

 kind-of, though the function name should be a string and not
 an integer (easier to extend/allocate), and it should allow
 return values in user-supplied buffers, same as ioctl/fcntl
 calls do.

dlsym()

-GAWollman



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: [kernel patch] fcntl(...) to close many descriptors


: As for the "generic" syscall mechanism, I'd love it. I think that
: there are many places where "names" would be good, instead of
: hardcoded numbers. The only problem is to find a way to do that
: without reducing performance. names are good. just try to see what it
: would be if filenames were replaced by inodes. I think that having a
: name-based mechanism makes it easier to add new syscalls or reject
: deprecated ones.
:
:Performance is not much of an issue.  A perfect hash can be generated
:for syscall names.

This is a bad idea.  One of the reasons why it is so easy for us to
write portability modules for Sun, Linux, etc... is because of the
hard-coded syscall numbers.  Syscalls work plenty well enough as they
are now, we do not need a new mechansm.

: (thanks to svr4 lobbying into posix:).
: - add a closeall macro to call it.
: 
: this gives both aix and netbsd compat (and if the fcntl thing goes into 
: netbsd, the compat would be full).
:
:I really do not care for using fcntl with this.  fcntl operates on a 
:single file descriptor -- F_CLOSEM mucks up the interface.
:
:-- 
:Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]

mmap() is overloaded for MAP_ANON.  fcntl() may not be perfect, but
it's better then adding a new syscall. 

The libc closeall() code (I'm assuming that Mouss does not intend to
actually use a #define) could do the fcntl(), and if it fails fall
back to close()ing descriptors in a loop.  Perfect!

-Matt



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Kernel Hacking (i tried not to make it lame)

2001-01-29 Thread Brooks Davis


On Fri, Jan 26, 2001 at 08:35:54AM -0700, Wes Peters wrote:
 Several others have made good replies to this, but here's another thought:
 The best way to learn something is to have a goal in mind.  If you understand
 C pretty well, pick a PR out of the problem report database and start working
 on that.  It will give you a starting point and a goal.

Another place other then the PR system to find a goal is on of PHK's
periodic tasks for "Junior Kernel Hackers" sorts of posts.  For instance
I implemetend the almost-clone hack on the snp device which was an
intresting experience.

-- Brooks

-- 
Any statement of the form "X is the one, true Y" is FALSE.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: [kernel patch] fcntl(...) to close many descriptors


At 09:37 29/01/01 -0800, Matt Dillon wrote:
This is a bad idea.  One of the reasons why it is so easy for us to
 write portability modules for Sun, Linux, etc... is because of the
 hard-coded syscall numbers.  Syscalls work plenty well enough as they
 are now, we do not need a new mechansm.

true, but if the same idea gets adopted by those many OSes, then it's a benefit
for them all. just how PAM came: it was non-portabble before adoption!





To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: [kernel patch] fcntl(...) to close many descriptors


At 08:57 29/01/01 -0800, Luigi Rizzo wrote:
hi,
i have to admit i am not too much into theory of hashing, but i am
unclear on how a perfect hash function can be simpler than "the
obvious method" when the namespace is changing dynamically because
modules are added or deleted.
(the obvious method would be a cheap hash on 2-4 chars of
the name followed by a scan of the list in each hash slot.)

one way would be to rehash when a syscall is added. hopefully, you want spend
your time adding'em. but it is probable that even this is unneded, though 
one still
needs to check.
for example, when adding named_syscall("foo", args), you compute 
hash("foo") using
the "current hash function, you try to insert it, and if you have a 
collision, you recompute
the hashes.
but, yes, this is over-engineering...



Hopefully the number of functions using this method is
small enough not to worry about the depth of the lists,
and the type of calls using this method is one where the amt
of work in the syscall itself is way larger than the matching cost.

yes, one can just strcmp() through the list. it's what filesystem code does 
anyway,
and there are far more files than there are syscalls.




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: [kernel patch] fcntl(...) to close many descriptors


At 12:28 29/01/01 -0500, Garrett Wollman wrote:
On Sun, 28 Jan 2001 12:45:10 -0800 (PST), Luigi Rizzo [EMAIL PROTECTED] 
said:

  kind-of, though the function name should be a string and not
  an integer (easier to extend/allocate), and it should allow
  return values in user-supplied buffers, same as ioctl/fcntl
  calls do.

dlsym()

you mean at user level?
That's certainly possible, but I think this is way more than we need.
strcmp() is ok given the number of syscalls.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Using multiple Malloc-Disks

2001-01-29 Thread David E. Cross


I need to use multiple malloc disks for a custom net-boot image I am working
on.  The problem is that whenever I access /dev/md1 from the disk it gives
me a 'device not configured' error.  I originally thought that this was an
error in how a preloaded image interfaced with the system, but I also get
this on a disk-booted machine.

Consider the following test:

 dd bs=512 if=/dev/md0c of=/dev/null
 2 Blocks in
 2 Blocks out
 
 dd bs=512 if=/dev/md1c of=/dev/null
 Device not configured.

Yet, according to the manpage:
 The md driver uses the ``almost-clone'' convention, whereby opening de-
 vice number N creates device instance number N+1.

What is wrong here?   A quick look through the source finds there is no code
in the open() routine to create a new instance; though I am not entirely sure
that is where it would be located.

--
David Cross   | email: [EMAIL PROTECTED] 
Lab Director  | Rm: 308 Lally Hall
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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

newbie - Audio CD question

2001-01-29 Thread vijay


Hi, I am new to FreeBSD. I wanted to know if I can play audio
CDs on "my" system. I have culled the following information from
dmesg

wdc0 at 0x1f0-0x1f7 irq 14 on isa
wdc0: unit 0 (wd0): FUJITSU MPC3064AT
wd0: 6187MB (12672450 sectors), 13410 cyls, 15 heads, 63 S/T,
512 B/S
wdc1 at 0x170-0x177 irq 15 on isa
wdc1: unit 0 (atapi): TOSHIBA CD-ROM XM-6402B/1008, removable,
accel, dma, iordis
acd0: drive speed 5512KB/sec, 256KB cache
acd0: supported read types: CD-R, CD-RW, CD-DA
acd0: Audio: play, 16 volume levels
acd0: Mechanism: ejectable tray
acd0: Medium: no/blank disc inside, unlocked

I also looked at the freebsd/ports collection under audio and
found a lot of packages but I am not sure if they will work for
"my" system. How can I find that ou? Which of these packages
would be the best if I can do it? Also, would I need to change
the kernel configuration and do a kernel recompile?

TIA
v.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: [kernel patch] fcntl(...) to close many descriptors


 It doesn't solve anything.  Besides, there is no such thing as a 
 perfect hash ... at least not one that has a small enough index range
 to be useful in a table lookup.  And, again, no real reason or need
 to do such a thing.  The kernel syscall is hardwired because it is
 the defining interface between userland and kernelland, and hardwiring
 it gives us the best, longest term stability in regards to portability.
 We don't need to pollute it with fancy algorithms that we may decide
 we have to 'adjust' every year or two.  One of the reasons why binary

i do not get the problem. The search key passed to the kernel would
be just a string, just like open() and sysctlbyname() calls handle.
And, this mechanism would be explicitly used for "non portable" or
experimental functions (such as the closeall() which started the
thread, or next time someone comes up with a start_http_server_thread())
and avoiding overloading an existing syscall or having to modify
libc would be beneficial in terms of code clarity (you know what the
thing is going to do) and portability.

cheers
luigi

--+-
 Luigi RIZZO, [EMAIL PROTECTED]  . ACIRI/ICSI (on leave from Univ. di Pisa)
 http://www.iet.unipi.it/~luigi/  . 1947 Center St, Berkeley CA 94704
 Phone: (510) 666 2927
--+-


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: [kernel patch] fcntl(...) to close many descriptors


On Mon, 29 Jan 2001 11:02:45 -0800 (PST), Luigi Rizzo [EMAIL PROTECTED] said:

 And, this mechanism would be explicitly used for "non portable" or
 experimental functions (such as the closeall() which started the
 thread, or next time someone comes up with a start_http_server_thread())
 and avoiding overloading an existing syscall or having to modify
 libc

This assumes that experimental functionality is always going to
implemented as a system call.

-GAWollman



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: [kernel patch] fcntl(...) to close many descriptors


:true, but if the same idea gets adopted by those many OSes, then it's a benefit
:for them all. just how PAM came: it was non-portabble before adoption!
:

It doesn't solve anything.  Besides, there is no such thing as a 
perfect hash ... at least not one that has a small enough index range
to be useful in a table lookup.  And, again, no real reason or need
to do such a thing.  The kernel syscall is hardwired because it is
the defining interface between userland and kernelland, and hardwiring
it gives us the best, longest term stability in regards to portability.
We don't need to pollute it with fancy algorithms that we may decide
we have to 'adjust' every year or two.  One of the reasons why binary
compatibility works so well over many years is the simplicity of API.

-Matt



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: [kernel patch] fcntl(...) to close many descriptors


 On Mon, 29 Jan 2001 11:02:45 -0800 (PST), Luigi Rizzo [EMAIL PROTECTED] said:
 
  And, this mechanism would be explicitly used for "non portable" or
  experimental functions (such as the closeall() which started the
  thread, or next time someone comes up with a start_http_server_thread())
  and avoiding overloading an existing syscall or having to modify
  libc
 
 This assumes that experimental functionality is always going to
 implemented as a system call.

that was the context of the thread as it evolved -- finding
non-intrusive ways to add new or experimental syscalls without
having to change kernel, libc or the like.

As a matter of fact, you could easily provide (in the libc stub)
hooks to add/remove names (and corresponding userland functions)
that are tried by this new call either before or after passing
control to the kernel version.

The generic method would basically have the same interface as ioctl()
or fcntl(), with the fd replaced by a pointer to the function name.

cheers
luigi
--+-
 Luigi RIZZO, [EMAIL PROTECTED]  . ACIRI/ICSI (on leave from Univ. di Pisa)
 http://www.iet.unipi.it/~luigi/  . 1947 Center St, Berkeley CA 94704
 Phone: (510) 666 2927
--+-


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: [kernel patch] fcntl(...) to close many descriptors

2001-01-29 Thread Alfred Perlstein


* Luigi Rizzo [EMAIL PROTECTED] [010129 11:16] wrote:
  On Mon, 29 Jan 2001 11:02:45 -0800 (PST), Luigi Rizzo [EMAIL PROTECTED] said:
  
   And, this mechanism would be explicitly used for "non portable" or
   experimental functions (such as the closeall() which started the
   thread, or next time someone comes up with a start_http_server_thread())
   and avoiding overloading an existing syscall or having to modify
   libc
  
  This assumes that experimental functionality is always going to
  implemented as a system call.
 
 that was the context of the thread as it evolved -- finding
 non-intrusive ways to add new or experimental syscalls without
 having to change kernel, libc or the like.
 
 As a matter of fact, you could easily provide (in the libc stub)
 hooks to add/remove names (and corresponding userland functions)
 that are tried by this new call either before or after passing
 control to the kernel version.
 
 The generic method would basically have the same interface as ioctl()
 or fcntl(), with the fd replaced by a pointer to the function name.

Actually, the easiest way if to make a sysctl that exports the syscall
number to useland.

mysubsystem.foosyscall: 188

:)

-- 
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
"I have the heart of a child; I keep it in a jar on my desk."


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: [kernel patch] fcntl(...) to close many descriptors


  The generic method would basically have the same interface as ioctl()
  or fcntl(), with the fd replaced by a pointer to the function name.
 
 Actually, the easiest way if to make a sysctl that exports the syscall
 number to useland.
 
 mysubsystem.foosyscall: 188

but there is a problem with syscall() in that according to
the manpages it cannot handle in/out parameters as instead
it is supported by ioctl/fcntl

am i mistaken ?

cheers
luigi



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: newbie - Audio CD question

2001-01-29 Thread Dan Feldman


There are two ways to play CDs. YOu can either tell the CD player to start
playing and have it do all the work, or actually read the CD in software,
interpret it, and send it to the speakers. The hardware method is nice
because it uses no CPU power and the audio control buttons on the fron tof
the drive work, but you usually need a special audio cable connecting the
CD player and sound card (unless you intend to play through
headphones). There are tons of free programs that can play CDs this way,
just cd to /usr/ports and type make search key=cd.

Using the all-software method is more complicated, bbut it lets you save
portions of the audio to a file, do software mixing, etc. But it can take
up quite a bit of CPU time on slower systems. A lot of audio-recording
programs and audio-editing programs use this method to play CDs. I know of
a few good programs like this for Linux but I haven't tried them on
FreeBSD, and I'm pretty sure they're not in the ports tree.

Anyone else want to clarify?



-- Dan Feldman

On Mon, 29 Jan 2001, vijay wrote:

 Hi, I am new to FreeBSD. I wanted to know if I can play audio
 CDs on "my" system. I have culled the following information from
 dmesg
 
 wdc0 at 0x1f0-0x1f7 irq 14 on isa
 wdc0: unit 0 (wd0): FUJITSU MPC3064AT
 wd0: 6187MB (12672450 sectors), 13410 cyls, 15 heads, 63 S/T,
 512 B/S
 wdc1 at 0x170-0x177 irq 15 on isa
 wdc1: unit 0 (atapi): TOSHIBA CD-ROM XM-6402B/1008, removable,
 accel, dma, iordis
 acd0: drive speed 5512KB/sec, 256KB cache
 acd0: supported read types: CD-R, CD-RW, CD-DA
 acd0: Audio: play, 16 volume levels
 acd0: Mechanism: ejectable tray
 acd0: Medium: no/blank disc inside, unlocked
 
 I also looked at the freebsd/ports collection under audio and
 found a lot of packages but I am not sure if they will work for
 "my" system. How can I find that ou? Which of these packages
 would be the best if I can do it? Also, would I need to change
 the kernel configuration and do a kernel recompile?
 
 TIA
 v.
 
 
 
 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: [kernel patch] fcntl(...) to close many descriptors


On Mon, 29 Jan 2001 11:26:29 -0800 (PST), Luigi Rizzo [EMAIL PROTECTED] said:

 but there is a problem with syscall() in that according to
 the manpages it cannot handle in/out parameters as instead
 it is supported by ioctl/fcntl

Of course it can, and the manual page doesn't even suggest what you
say.  It says:

 There is no way to simulate system calls that have multiple return values
 such as pipe(2).

pipe(2) is a special case in that it returns two values rather than
one.  The actual pipe(2) system call has *no* formal parameters; the
unpacking of the two values returned into the declared C formal
parameter is done by an assembly-language stub.  (This was done for
reasons of speed; it is much faster to return two values than it is to
copyout() a two-element array.

If you were implementing a Lisp binding of POSIX, you would probably
define PIPE to be a niladic function which returns a list of two
descriptors.

-GAWollman



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: [kernel patch] fcntl(...) to close many descriptors


 Of course it can, and the manual page doesn't even suggest what you
 say.  It says:
 
  There is no way to simulate system calls that have multiple return values
  such as pipe(2).

ok, sorry for the confusion then (though, how does one tell from
the manpage for pipe(2) what is going on there!)

cheers
luigi

 pipe(2) is a special case in that it returns two values rather than
 one.  The actual pipe(2) system call has *no* formal parameters; the
 unpacking of the two values returned into the declared C formal
 parameter is done by an assembly-language stub.  (This was done for
 reasons of speed; it is much faster to return two values than it is to
 copyout() a two-element array.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: [kernel patch] fcntl(...) to close many descriptors


On Mon, 29 Jan 2001 12:07:11 -0800 (PST), Luigi Rizzo [EMAIL PROTECTED] said:

 ok, sorry for the confusion then (though, how does one tell from
 the manpage for pipe(2) what is going on there!)

You're not supposed to -- it's an implementation detail.

-GAWollman



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Bash2 removes SSH_CLIENT from the environment

2001-01-29 Thread Patrick Bihan-Faou


Hi,

I am writing some script that looks for the SSH_CLIENT environment variable.
As specified in the sshd(8) man page, this variable should contain the IP
address of the client, the port number on the client side and the port
number on the server side.

However I found that if the login shell of the user is set to bash (version
2.03 or 2.04 at least), this variable is never set. Upon inspection of the
code for bash, it appears that bash is explicitely removing the definition
of this environment variable. Would anybody have an idea why ???

Also the fix to leave SSH_CLIENT defined is trivial, is that something that
would be desirable for the bash2 port ?

Patrick.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: [kernel patch] fcntl(...) to close many descriptors

2001-01-29 Thread Bakul Shah


This caught my eye:

 Besides, there is no such thing as a
 perfect hash ... at least not one that has a small enough index range
 to be useful in a table lookup.

If you can get to old CACMs see `Minimal Perfect Hash Functions Made Simple'
by Richard J. Cichelli, Comm. of ACM, Jan 1980.  AFAIK gperf uses some
variation of that algorithm and may have some details.  A minimal perfect hash
function is only worth it (IMHO) when the set of input keys is mostly fixed and
the hash function is used many many times (e.g. programming language keywords).

As for a generic  extensible syscall, you'd have to pay the cost of finding
a new minimal perfect hash function every time you load a kernel module that
implements a new system call.  AFAIK the best algo. to generate a new perfect
hash function runs in O(n log n) time -- not too bad (kernel module loading
doesn't have to be lightening fast) but even for an experimental syscall the
time to reach syscall code should be minimized if it is to ever get past the
experimental stage.  Someone mentioned discovering the syscall name-index
mapping via sysctl but that opens up a window where the mapping can change.

For what its worth...

-- bakul


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: [kernel patch] fcntl(...) to close many descriptors

2001-01-29 Thread Poul-Henning Kamp


In message [EMAIL PROTECTED], Bakul Shah writes:
This caught my eye:

 Besides, there is no such thing as a
 perfect hash ... at least not one that has a small enough index range
 to be useful in a table lookup.

If you can get to old CACMs see `Minimal Perfect Hash Functions Made Simple'
by Richard J. Cichelli, Comm. of ACM, Jan 1980.  AFAIK gperf uses some
variation of that algorithm and may have some details.  A minimal perfect hash
function is only worth it (IMHO) when the set of input keys is mostly fixed and
the hash function is used many many times (e.g. programming language keywords).

And even then it's seldom worth it according to the people behind the LCC
compiler...

--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

EBCDIC - ASCII

2001-01-29 Thread Josef Grosch



Does anybody know of an EBCDIC to ASCII converter? I thought that at one
time FreeBSD had one of these.


Josef

-- 
Josef Grosch   | Another day closer to a | FreeBSD 4.2
[EMAIL PROTECTED] |   Micro$oft free world  | www.bafug.org



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: EBCDIC - ASCII

2001-01-29 Thread Poul-Henning Kamp


In message [EMAIL PROTECTED], Josef Grosch writes:

Does anybody know of an EBCDIC to ASCII converter? I thought that at one
time FreeBSD had one of these.

man 1 dd

--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: EBCDIC - ASCII

2001-01-29 Thread Drew Eckhardt


In message [EMAIL PROTECTED], [EMAIL PROTECTED] write
s:

Does anybody know of an EBCDIC to ASCII converter? I thought that at one
time FreeBSD had one of these.

This is a standard dd(1) feature.  More specifically, you want to use the
conv=ascii option.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: EBCDIC - ASCII

2001-01-29 Thread Thomas David Rivers


Josef Grosch [EMAIL PROTECTED] wrote:
 
 
 Does anybody know of an EBCDIC to ASCII converter? I thought that at one
 time FreeBSD had one of these.
 
 
 Josef

 Check out the `dd' command.. particularly the `conv' suboption:

 conv= value[, value ...]
  Where value is one of the symbols from the following list.

  ascii, oldascii
   The same as the unblock value except that characters
   are translated from EBCDIC to ASCII before the records
   are converted.  (These values imply unblock if the
   operand cbs is also specified.)  There are two conver-
   sion maps for ASCII. The value ascii specifies the rec-
   ommended one which is compatible with System V.  The
   value oldascii specifies the one used in historic ATT
   and pre-4.3BSD-reno systems.

- Dave Rivers -

--
[EMAIL PROTECTED] Work: (919) 676-0847
Get your mainframe (370) `C' compiler at http://www.dignus.com


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: EBCDIC - ASCII

2001-01-29 Thread Josef Grosch


On Mon, Jan 29, 2001 at 10:35:20PM +0100, Poul-Henning Kamp wrote:
 In message [EMAIL PROTECTED], Josef Grosch writes:
 
 Does anybody know of an EBCDIC to ASCII converter? I thought that at one
 time FreeBSD had one of these.
 
 man 1 dd

Doh! Time to re-read the man pages. Thanks

Josef

-- 
Josef Grosch   | Another day closer to a | FreeBSD 4.2
[EMAIL PROTECTED] |   Micro$oft free world  | www.bafug.org



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Really odd BTX halted problem booting - PXE/diskless

2001-01-29 Thread John Baldwin



On 29-Jan-01 Danny Braniss wrote:
 im now being bitten by this one, but with a twist:
  on a compaq deskpro workstation it's ok
  on a dell-precision 420, it bombs.
 both bioses are configured to boot via the network/pxe.
 
 im using the same disks for both boxes.
 
 i labeled the disks with:
  dd if=/dev/zero of=/dev/rda0 bs=1k count=1
  disklabel -Brw da0 auto
 
 i then went ahead an played with vinum, all went fine on the Compaq,
 i then wanted to do some comparisons, so i hooked up the disks to the Dell
 and now BTX bombs. 
 
 is there a way, that when booting from the net, btx ignores the mbr/fdisk
 info?

BTX doesn't read your MBR, it sounds like the BIOS in the machine is crapping
itself out on the disks in question.  If you are using dangerously dedicated
mode on these disks, don't. :)

-- 

John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: [kernel patch] fcntl(...) to close many descriptors

2001-01-29 Thread Bakul Shah


 If you can get to old CACMs see `Minimal Perfect Hash Functions Made Simple'
 by Richard J. Cichelli, Comm. of ACM, Jan 1980.  AFAIK gperf uses some
 variation of that algorithm and may have some details.  A minimal perfect hash
 function is only worth it (IMHO) when the set of input keys is mostly fixed and
 the hash function is used many many times (e.g. programming language keywords).
 
 And even then it's seldom worth it according to the people behind the LCC
 compiler...

I'd be interested in a reference if you have one [I don't doubt you, just
curious).

I used gperf to generate such a function in a verilog parser and came to
the same conclusion but it can't be generalized to the syscall (or for
that matter database) case.  The reason it doesn't buy much in a compiler
is because what is not a keyword is an identifier and you end up doing a symbol
table lookup on it.  So you may as well just do a symbol table search for
everything (also, typically there are more identifiers than keywords in a
program so it all comes out in a wash).  This is not the case for a simple
lookup (database or syscall) -- you don't do another lookup on the same
string if the first search fails.

I agree that for a very small number of syscalls a simple hash or even
a strcmp is good enough but that doesn't scale well.  Min. perfect hash
function is about as good as it gets *if* one wants to allow for a large
number of loadable syscalls *without* apriori assignment of numbers.  With
an IANA like central number assigning authority, preassignment of syscall
numbers is far better.

-- bakul


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: [kernel patch] fcntl(...) to close many descriptors

:
:They say so in their book:
:
:http://www.amazon.com/exec/obidos/ASIN/0805316701/qid=980806275/sr=1-28/ref=sc_b_28/104-5366240-4220700
:
:
:--
:Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
:[EMAIL PROTECTED] | TCP/IP since RFC 956
:FreeBSD committer | BSD since 4.3-tahoe

And they are right. When I wrote DICE (Ansi C compiler for the Amiga),
I tried to use something similar to a perfect hash for keyword and
string element references in the lexer token, to reduce the amount of
meta-data I needed to store in the token. I thought it would be very
cool, but it turned out not to help at all. It actually made debugging
more difficult. I wound up simply using a string table and converting
strings to a pointer into the string table. This worked a whole lot
better.

USENET news systems, including my own Diablo, use a big hash with a low
probability of conflict to map the message-id's into the history database.
Diablo used a 64 bit CRC. I believe INN has moved to using MD5's.
These are not perfect hashes but the serve much the same purpose -
reducing a variable length string into a constant-length key. I would
argue that the hash/key construct is useful when you are dealing with
millions or hundreds of millions of discrete pieces of information
(as a news system must), but not so useful for something like a syscall
table where long term portability is more important.

If you need syscalls for experimental ops, just assign high syscall
numbers not likely to be used by others during your experiment. It's
no biggy.

-Matt

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

RE: Kernel Hacking (i tried not to make it lame)

2001-01-29 Thread Doug Barton


On Fri, 26 Jan 2001, Koster, K.J. wrote:

 Dear Ariff,

 
  I remembered porting back cd9660 to 2.2.x tree, and now look
  forward porting softupdates (If anybody can give me some light
  I really appreciate that). I'm reviewing sources from current,
  stable and from other BSD project such OpenBSD to pick all
  the good stuffs.
  I'm a happy 2.2.x user.
 
 I think Yahoo! is using still on 2.2.8.

Don't let your imagination run away with you. :)

Doug
-- 
"Pain heals. Chicks dig scars. Glory . . . lasts forever."
-- Keanu Reeves as Shane Falco in "The Replacements"

Do YOU Yahoo!?




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Snowhite and the Seven Dwarfs - The REAL story!

2001-01-29 Thread Julian Stacey [EMAIL PROTECTED]


 A few months ago someone suggested that all binary attachments should be
 stripped from freebsd-hackers mail. I believe it is still a very good idea,
 and patches tend to be posted as text anyway.

Good Idea.

We should'nt filter out all mail with MIME enclosures, as occasionally MIME 
enclosures are validly used on FreeBSD lists, But to list a few WIBNIs:
(WIBNI = Woundn't It Be Nice If )

We could bounce/kill all postings containing MIME with .exe spam.
 (We have uuencode in the rare event we need to broadcast a binary.)

We could bounce/kill postings containing MIME with .doc enclosures, stopping:
 more spam  EG non Unix oriented people dumping .doc resumes on jobs@freebsd.
 OK, it would also reject .doc format job adverts, some may not like that,
 but if a company is so uncaring/incompetent they can't even reformat a
 bounced .doc in ascii or some public format, I'm not interested.

We could also bounce/kill postings containing 
Content-Type: text/html; charset=big5
 other non latin fonts, as we all use latin fonts on freebsd lists,
it being the only one we all understand.  Sure some people set 
charset=big5
by mistake ( then send ascii anyway),  they are discussing real FreeBSD
issues, but it'd cut spam from non latin charset originators.

We could also bounce/kill postings containing possibly auto-load HREFs ?
(Do they exist as such ? I got one direct, not from a BSD list, 
looks rather innocuous initially, starting:
] -
] MIME-Version: 1.0
] Content-Type: text/html; charset=big5
] Content-Transfer-Encoding: base64
] 
] PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u
] YWwvL0VOIj4NCjxIVE1MPjxIRUFEPjxUSVRMRT6rT67JsbazbsXppUCsyTwvVElUTEU+DQo8
] TUVUQSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9YmlnNSIgaHR0cC1lcXVpdj1Db250
] ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4wMC4yNjE0LjM1MDAiIG5hbWU9
] R0VORVJBVE9SPjwvSEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZiBsZWZ0TWFyZ2luPTAg
] dG9wTWFyZ2luPTA+DQo8VEFCTEUgYm9yZGVyPTAgY2VsbFBhZGRpbmc9MCBjZWxsU3BhY2lu
] 
But EXMH hangs seemingly waits for my gateway,  can also can show it as:
] 
] !DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
] HTMLHEADTITLE???/TITLE
] META content="text/html; charset=big5" http-equiv=Content-Type
] META content="MSHTML 5.00.2614.3500" name=GENERATOR/HEAD
] BODY bgColor=#ff leftMargin=0 topMargin=0
] TABLE border=0 cellPadding=0 cellSpacing=0 width="100%"
]   TBODY
]   TR
] TD bgColor=#c4 width="100%"BRBRBR/TD/TR
]   TR
] TD bgColor=#ff width="100%"BR/TD/TR/TBODY/TABLE
] DIV align=center
] CENTER
] TABLE border=0 cellPadding=0 cellSpacing=0 height=80 width="67%"
]   TBODY
]   TR
] TD height=18 width="65%"!--webbot bot="ImageMap" startspan
] rectangle=" (6,6) (325, 169)  http://www.geocities.com/kino33us" 
]src="http://www.geocities.com/ad12223/maillogo.gif" width="326" height="170"
] alt="http://www.geocities.com/ad12223/maillogo.gif (9955 )"
] --
(BTW It doesnt work, geocities says kino33us/por.css doesnt exist,
 though the spam is not old:
] Received: from unknown (HELO dns.swaintpe.com.tw) (202.39.37.101)
]   by slarti.muc.de with SMTP; 28 Jan 2001 10:00:41 -
] Received: from 202.39.37.101 ([163.30.2.207]) by dns.swaintpe.com.tw (Lotus SMTP MTA 
]SMTP v4.6 (462.2 9-3-1997)) with SMTP id 482569E2.0035B74C; Wed, 28 Jan 1970 17:46:55 
]+0800
)

Anyone who could give [EMAIL PROTECTED] filter mechanisms that
freebsd.org could integrate to reduce spam on lists, would be a minor hero :-)

Julian
-
Julian Stacey Unix Consultant - Munich Germany http://bim.bsn.com/~jhs/
Considering Linux ? Try FreeBSD with 4200 packages !
 Ihr Rauchen = mein allergischer Kopfschmerz !  Kau/Schnupftabak probieren !


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Suboptimal mmap of devices on i86

2001-01-29 Thread Drew Eckhardt


On i86 boxes with 4M page capabilities, we want contiguous chunks
of physical address space for mmaped devices to use those larger pages 
when possible.

In practice, this doesn't happen in applications linked with shared
libraries when mmap() is used in the usual way with 0 as the address 
argument and no MAP_FIXED flag.

mmap() passes vm_mmap() a starting address after the heap.  vm_mmap() 
adjusts this with pmap_addr_hint(), and the result propogates down to 
vm_map_findspace().  When there's insufficient free space to map the 
object at the optimally aligned address because a shared library
is already there, vm_map_findspace() returns the first fit without
adjusting the starting address.

I tweaked my kernel as follows to get pmap_object_init_pt() functioning
as designed.  

--- old Mon Jan 29 16:03:40 2001
+++ vm/vm_map.c Fri Jan 26 18:47:24 2001
@@ -169,6 +169,8 @@
 static void vm_map_copy_entry __P((vm_map_t, vm_map_t, vm_map_entry_t,
vm_map_entry_t));
 static void vm_map_split __P((vm_map_entry_t));
+static int vm_map_findspace_for_object __P((vm_map_t, vm_object_t, vm_offset_t,
+   vm_size_t, vm_offset_t *));
 
 void
 vm_map_startup()
@@ -775,10 +777,20 @@
 /*
  * Find sufficient space for `length' bytes in the given map, starting at
  * `start'.  The map must be locked.  Returns 0 on success, 1 on no space.
+ * 
+ * This differs from the stock vm_map_findspace() in that we have an 
+ * additional parameter (object) which is used to get hints from the
+ * pmap layer which may result in stricter (coarser) alignment.
+ *
+ * FIXME: This should probably replace vm_map_findspace entirely.
+ * We may also want to revert to the historic behavior on failure, in the 
+ * rare event that we have space for the requested region but not at the
+ * optimal alignment suggested by pmap_addr_hint().
  */
-int
-vm_map_findspace(map, start, length, addr)
+static int
+vm_map_findspace_for_object(map, object, start, length, addr)
vm_map_t map;
+   vm_object_t object;
vm_offset_t start;
vm_size_t length;
vm_offset_t *addr;
@@ -811,6 +823,7 @@
 * gap between existing regions, or after the very last region.
 */
for (;; start = (entry = next)-end) {
+   start = pmap_addr_hint(object, start, length);
/*
 * Find the end of the proposed new region.  Be sure we didn't
 * go beyond the end of the map, or wrap around the address;
@@ -837,6 +850,21 @@
 }
 
 /*
+ * Find sufficient space for `length' bytes in the given map, starting at
+ * `start'.  The map must be locked.  Returns 0 on success, 1 on no space.
+ */
+int
+vm_map_findspace(map, start, length, addr)
+   vm_map_t map;
+   vm_offset_t start;
+   vm_size_t length;
+   vm_offset_t *addr;
+{
+   return (vm_map_findspace_for_object (map, NULL, start, length, 
+   addr));
+}
+
+/*
  * vm_map_find finds an unallocated region in the target address
  * map with the given length.  The search is defined to be
  * first-fit from the specified address; the region found is
@@ -859,7 +887,8 @@
 
vm_map_lock(map);
if (find_space) {
-   if (vm_map_findspace(map, start, length, addr)) {
+   if (vm_map_findspace_for_object(map, object, start, length, 
+   addr)) {
vm_map_unlock(map);
if (map == kmem_map || map == mb_map)
splx(s);


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Suboptimal mmap of devices on i86