freebsd-hackers Digest, Vol 15, Issue 1
freebsd-hac...@freebsd.org
freebsd...@freebsd.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
or, via email, send a message with subject or body 'help' to
freebsd-hac...@freebsd.org
You can reach the person managing the list at
freebsd-ha...@freebsd.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of freebsd-hackers digest..."
Today's Topics:
1. Re: Questions (Raunchy McSmutbag)
2. Re: Mounting (Roman Neuhauser)
3. How to convert a linux-src to access APC USB HID on FreeBSD?
(Riccardo Torrini)
4. Re: Drawing graphics on terminal (Roman Neuhauser)
5. Re: open() and ESTALE error (Don Lewis)
6. per-directory quotas possible on 5.x ? (Josh Brooks)
7. Your message to cisco-nsp awaits moderator approval
(cisco-ns...@puck.nether.net)
8. [newbie] Allocating memory in kernel land (Paolo Pisati)
9. Re: Fwd: Re: TODO list? (Paul Robinson)
10. Re: Questions (Paul Robinson)
11. Re: TODO list? (Maxim Konovalov)
12. Re: TODO list? (Christopher Arnold)
13. gethostbyname_r (Stijn Hoop)
14. Re: gethostbyname_r (Simon L. Nielsen)
15. Re: gethostbyname_r (Hajimu UMEMOTO)
16. Looking for RealTek 8169-based NIC for testing (Bill Paul)
17. Re: per-directory quotas possible on 5.x ? (Robert Watson)
----------------------------------------------------------------------
Message: 1
Date: Sun, 29 Jun 2003 20:02:05 +0000
From: "Raunchy McSmutbag" <int...@hotmail.com>
Subject: Re: Questions
To: radical...@hotmail.com, freebsd...@freebsd.org
Message-ID: <Law11-F96dxGE...@hotmail.com>
Content-Type: text/plain; format=flowed
becuz you obviously have no idea what this list is about
>From: "Edward Tiruvsky" <radical...@hotmail.com>
>To: int...@hotmail.com
>Subject: Re: Questions
>Date: Sun, 29 Jun 2003 19:18:09 +0000
>MIME-Version: 1.0
>X-Originating-IP: [63.185.112.139]
>X-Originating-Email: [radical...@hotmail.com]
>Received: from 63.185.112.139 by by1fd.bay1.hotmail.msn.com with HTTP;Sun,
>29 Jun 2003 19:18:09 GMT
>
>why?
>
>
>>From: "Raunchy McSmutbag" <int...@hotmail.com>
>>To: radical...@hotmail.com
>>Subject: Re: Questions
>>Date: Sun, 29 Jun 2003 18:19:35 +0000
>>
>>may i ask how you came across this mailing list?
>>
>>>From: "Edward Tiruvsky" <radical...@hotmail.com>
>>>To: int...@hotmail.com
>>>Subject: Re: Questions
>>>Date: Sun, 29 Jun 2003 18:14:34 +0000
>>>MIME-Version: 1.0
>>>X-Originating-IP: [63.185.112.139]
>>>X-Originating-Email: [radical...@hotmail.com]
>>>Received: from 63.185.112.139 by by1fd.bay1.hotmail.msn.com with
>>>HTTP;Sun, 29 Jun 2003 18:14:34 GMT
>>>
>>>don't hackers deal with security stuff and all that?
>>>
>>>
>>>>From: "Raunchy McSmutbag" <int...@hotmail.com>
>>>>To: radical...@hotmail.com
>>>>Subject: Re: Questions
>>>>Date: Sun, 29 Jun 2003 17:49:35 +0000
>>>>
>>>>how do you figure?
>>>>
>>>>
>>>>>From: "Edward Tiruvsky" <radical...@hotmail.com>
>>>>>To: int...@hotmail.com
>>>>>Subject: Re: Questions
>>>>>Date: Sun, 29 Jun 2003 17:08:22 +0000
>>>>>MIME-Version: 1.0
>>>>>X-Originating-IP: [63.185.104.236]
>>>>>X-Originating-Email: [radical...@hotmail.com]
>>>>>Received: from 63.185.104.236 by by1fd.bay1.hotmail.msn.com with
>>>>>HTTP;Sun, 29 Jun 2003 17:08:22 GMT
>>>>>
>>>>>I think so
>>>>>
>>>>>
>>>>>>From: "Raunchy McSmutbag" <int...@hotmail.com>
>>>>>>To: radical...@hotmail.com, freebsd...@freebsd.org
>>>>>>Subject: Re: Questions
>>>>>>Date: Sun, 29 Jun 2003 16:34:16 +0000
>>>>>>
>>>>>>is this the right list to send this to?
>>>>>>
>>>>>>>From: "Edward Tiruvsky" <radical...@hotmail.com>
>>>>>>>To: freebsd...@freebsd.org
>>>>>>>Subject: Questions
>>>>>>>Date: Sun, 29 Jun 2003 08:57:46 +0000
>>>>>>>MIME-Version: 1.0
>>>>>>>X-Originating-IP: [158.253.192.33]
>>>>>>>X-Originating-Email: [radical...@hotmail.com]
>>>>>>>Received: from mx2.freebsd.org ([216.136.204.119]) by
>>>>>>>mc6-f33.law1.hotmail.com with Microsoft SMTPSVC(5.0.2195.5600); Sun,
>>>>>>>29 Jun 2003 01:58:35 -0700
>>>>>>>Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18])by
>>>>>>>mx2.freebsd.org (Postfix) with ESMTPid 86FC256E34; Sun, 29 Jun 2003
>>>>>>>01:58:01 -0700 (PDT)(envelope-from owner-free...@freebsd.org)
>>>>>>>Received: from hub.freebsd.org (localhost [127.0.0.1])by
>>>>>>>hub.freebsd.org (Postfix) with ESMTPid 7255237B405; Sun, 29 Jun 2003
>>>>>>>01:58:01 -0700 (PDT)
>>>>>>>Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])by
>>>>>>>hub.freebsd.org (Postfix) with ESMTP id 268B837B401for
>>>>>>><freebsd...@freebsd.org>;Sun, 29 Jun 2003 01:57:52 -0700 (PDT)
>>>>>>>Received: from hotmail.com (bay1-f53.bay1.hotmail.com
>>>>>>>[65.54.245.53])by mx1.FreeBSD.org (Postfix) with ESMTP id
>>>>>>>8B00744020for <freebsd...@freebsd.org>;Sun, 29 Jun 2003 01:57:51
>>>>>>>-0700 (PDT)(envelope-from radical...@hotmail.com)
>>>>>>>Received: from mail pickup service by hotmail.com with Microsoft
>>>>>>>SMTPSVC; Sun, 29 Jun 2003 01:57:46 -0700
>>>>>>>Received: from 158.253.192.33 by by1fd.bay1.hotmail.msn.com with
>>>>>>>HTTP;Sun, 29 Jun 2003 08:57:46 GMT
>>>>>>>X-Message-Info: EoYTbT2lH2MsQxQLKd6QGpQxvU17UYmU
>>>>>>>Delivered-To: freebsd...@freebsd.org
>>>>>>>Message-ID: <BAY1-F535b6KZ...@hotmail.com>
>>>>>>>X-OriginalArrivalTime: 29 Jun 2003 08:57:46.0747
>>>>>>>(UTC)FILETIME=[82975CB0:01C33E1C]
>>>>>>>X-BeenThere: freebsd...@freebsd.org
>>>>>>>X-Mailman-Version: 2.1.1
>>>>>>>Precedence: list
>>>>>>>List-Id: Technical Discussions relating to
>>>>>>>FreeBSD<freebsd-hackers.freebsd.org>
>>>>>>>List-Unsubscribe:
>>>>>>><http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,<mailto:freebsd-hac...@freebsd.org?subject=unsubscribe>
>>>>>>>List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers>
>>>>>>>List-Post: <mailto:freebsd...@freebsd.org>
>>>>>>>List-Help: <mailto:freebsd-hac...@freebsd.org?subject=help>
>>>>>>>List-Subscribe:
>>>>>>><http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,<mailto:freebsd-hac...@freebsd.org?subject=subscribe>
>>>>>>>Sender: owner-free...@freebsd.org
>>>>>>>Errors-To: owner-free...@freebsd.org
>>>>>>>Return-Path: owner-free...@freebsd.org
>>>>>>>
>>>>>>>i know this might be a long shot but ive got some questions and i was
>>>>>>>hoping someone could help me out or point me in the direction of
>>>>>>>someone who can...reply through the digest
>>>>>>>first off is it possible or even plausible to use several anonimous
>>>>>>>remailers to scramble an identity very well before sending it to the
>>>>>>>intended recipitent. in other words have one remailer be the head
>>>>>>>that sends the message to the next remailer which passes the message
>>>>>>>to another and so on until it reaches the end where the last remailer
>>>>>>>is directable and able to send the mail to whoever the user wishes.
>>>>>>>next i need to know of a good secure free domain. hotmail is good and
>>>>>>>all but who can really trust microsoft?
>>>>>>>im probably fogeting some of my questions but anyway thats all for
>>>>>>>now thanks
>>>>>>>radicaledward
>>>>>>>
>>>>>>>_________________________________________________________________
>>>>>>>MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*.
>>>>>>>http://join.msn.com/?page=features/virus
>>>>>>>
>>>>>>>_______________________________________________
>>>>>>>freebsd...@freebsd.org mailing list
>>>>>>>http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>>>>>>>To unsubscribe, send any mail to
>>>>>>>"freebsd-hacke...@freebsd.org"
>>>>>>
>>>>>
>>>>
>>>
>>
>
_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*.
http://join.msn.com/?page=features/featuredemail
------------------------------
Message: 2
Date: Sun, 29 Jun 2003 22:17:16 +0200
From: Roman Neuhauser <neuh...@bellavista.cz>
Subject: Re: Mounting
To: hac...@freebsd.org
Message-ID: <20030629201...@freepuppy.bellavista.cz>
Content-Type: text/plain; charset=us-ascii
# rwa...@freebsd.org / 2003-06-23 11:45:37 -0400:
> On Mon, 23 Jun 2003, Socketd wrote:
> > Would it be possible to have this configuration and not having the
> > system fail (because of lacking rights or something):
> > /var/mail noexec
>
> nosuid would be fine here also.
# Jan....@bristol.ac.uk / 2003-06-24 16:31:33 +0100:
> On Mon, 23 Jun 2003, Socketd wrote:
> > /tmp and /var/tmp noexec (I know /tmp has to be execuable to make
> > world)
>
> nosymfollow. I've not found anything that this breaks (except a
> gazillion symlink race exploits).
This questions will be probably extremely stupid:
why aren't these defaults?
--
If you cc me or remove the list(s) completely I'll most likely ignore
your message. see http://www.eyrie.org./~eagle/faqs/questions.html
------------------------------
Message: 3
Date: Sun, 29 Jun 2003 23:19:26 +0200
From: Riccardo Torrini <ricc...@torrini.org>
Subject: How to convert a linux-src to access APC USB HID on FreeBSD?
To: freebsd...@FreeBSD.org
Message-ID: <2003062921...@trudy.torrini.home>
Content-Type: text/plain; charset=us-ascii
Hi there,
I asked the same question to Nick Hibma but he is very busy and can't
help me. If someone know how to convert a linux-src to freebsd to
access my UPS I'd happy to test any piece of (non explosive) code he
sent me...
Also please Cc: me, I'm only on current@. Thanks in advance.
I'm trying to interface my new APC (RS 500) with FreeBSD 4.8-STABLE
(but if you make a -CURRENT only code I'm able to test it) but after
some search I found that all around there are only linux applications
and I'm unable to convert them myself to FreeBSD ones. Can you help me?
Looking on the net I found apcupsd-3.10.5 but it is a Linux-only src,
it has all protocol exposed, would be simple to convert (knowing how
linux works, at least). If you know how to help me to convert this
single src (linux-usb.c usb.h) to FreeBSD send me a note, I'll be
happy to test. I collect all under my local site:
ftp://ftp.torrini.org/pub/FreeBSD/APC-hacking/
Also note that linux-usb.c and usb.h are GPL-ed, I simple extract from
the original tarball without touching the code. If you need the whole
archive search for apcupsd-3.10.5.tar.gz on sourceforge.
Even a reduced version able only to acquire time and power would help.
# usbdevs -v -d
Controller /dev/usb0:
addr 1: self powered, config 1, UHCI root hub(0x0000), VIA(0x0000), rev 1.00
uhub0
port 1 powered
port 2 addr 2: low speed, self powered, config 1, \
Back-UPS RS 500 FW:30.j2.I USB FW:j2(0x0002), \
American Power Conversion(0x051d), rev 0.06
After playing with usbhidctl I found that my APC use 0xff84, 0xff85 and
0xff86 instead of 0x84, 0x85 and 0x86 as it would so I created a custom
file with the contents of /usr/share/misc/usb_hid_usage and with a copy
of pages 132/133 to 0xff84/0xff85 and now it decode pages/usages.
Now I'm at a dead end, usbhidctl say:
device does not support immediate mode, only changes reported.
but interrogating device with -a and/or -l show me only zeros.
If you need my config/boot.log feel free to download them from:
ftp://ftp.torrini.org/pub/FreeBSD/APC-hacking/
What else can I do (apart from changing UPS)?
I hope you can point me to the right direction (docs or ML)...
--
Riccardo. ( http://www.GUFI.org/~vic/ )
------------------------------
Message: 4
Date: Sun, 29 Jun 2003 23:53:38 +0200
From: Roman Neuhauser <neuh...@bellavista.cz>
Subject: Re: Drawing graphics on terminal
To: Paul Robinson <pa...@iconoplex.co.uk>
Cc: freebsd...@freebsd.org
Message-ID: <20030629215...@freepuppy.bellavista.cz>
Content-Type: text/plain; charset=us-ascii
# pa...@iconoplex.co.uk / 2003-06-18 11:01:25 +0100:
> On Mon, Jun 16, 2003 at 03:18:52PM -0400, Leo Bicknell wrote:
> > Some of this could be done in the current installer, if there wasn't
> > an effort to make it still fit on a floppy. Mind you, I'd like to see
> > the floppy based install stick around for a while, but I think FreeBSD
> > needs to embrace the CD reality.
> - A graphic installer would be nice though, because novice users need a bit
> of cuddling in those first few scary hours when new to the OS.
This would (and I viewed it this way when I started playing with OS
OSes) be plain lying. Pretty splash screen, and then what? A command
line? Pfff. I don't need a mascot winking at me from behind the
edges of the screen, I want an OS that's as fast as it gets. STABLE
on a P166/32MB RAM is faster than Mandrake 9.1 on a 400MHz Celeron
with 128MB RAM. I don't want FreeBSD to become another Mandrake.
Actually, I still remember installing FreeBSD for the first time (it
was 3.something, and I didn't return back till 4.0 or something when
I was actually determined to trying it out). I was scared, but I got
it to install. Sysinstall is not that bad if you follow the signs,
and quite managable if you don't.
YaST and whatever RedHat calls their installer amounted to a damn
lie to me. They promised things the running system didn't deliver,
and I felt cheated. If you *really* want to make FreeBSD more user
friendly, take a look at these man pages, and translate them into
English: disklabel(8), fdisk(8), newfs(8). Or mount_ntfs(8): what
the heck is a "nonresident file"?
The installer is just an eyecandy, and not seen very often.
--
If you cc me or remove the list(s) completely I'll most likely ignore
your message. see http://www.eyrie.org./~eagle/faqs/questions.html
------------------------------
Message: 5
Date: Sun, 29 Jun 2003 18:23:20 -0700 (PDT)
From: Don Lewis <truc...@FreeBSD.org>
Subject: Re: open() and ESTALE error
To: ui...@blackflag.ru
Cc: freebsd...@FreeBSD.org
Message-ID: <200306300123....@gw.catspoiler.org>
Content-Type: TEXT/plain; charset=us-ascii
On 22 Jun, Andrey Alekseyev wrote:
> Don,
>
>> When a file is renamed on the server, its file handle remains valid.
>
> Actually I was wrong in my assumption on how names are purged from the
> namecache. And I didn't mean an operation with a file opened on the client.
> And it actually happens that this sequence of commands will get you ENOENT
> (not ESTALE) on the client because of a new lookup in #4:
>
> 1. server: echo "1111" > 1
> 2. client: cat 1
> 3. server: mv 1 2
> 4. client: cat 1 <--- ENOENT here
That's what it is supposed to do, but my testing would seem to indicate
that step 4 could return the file contents for an extended period of
time after the file was renamed on the server.
> Name cache can be purged by nfs_lookup(), if the latter finds that the
> capability numbers doesn't match. In this case, nfs_lookup() will send a
> new "lookup" RPC request to the server. Name cache can also be purged from
> getnewvnode() and vclean(). Which code does that for the above scenario
> it's quite obscure to me. Yes, my knowledge is limited :)
The vpid == newvp->v_id test in nfs_lookup() just detects if the vnode
that the cache entry pointed to was recycled for another use while it
was on the free list. It doesn't detect whether the inode on the server
was recycled.
When I was thinking about this problem, the solution I came up with was
a lot like the
if (!VOP_GETATTR(newvp, &vattr, cnp->cn_cred, td)
&& vattr.va_ctime.tv_sec == VTONFS(newvp)->n_ctime)
code fragment, but I would have done the ctime check on both the target
and the parent directory and only ignored the cache entry if both ctimes
had been updated. Checking only the target should be more conservative,
though it would be slower because there would be more cases where the
client would have to do the RPC call.
If the file on the server associated with the cached entry on the client
is renamed on the server, its file handle will remain valid, but its
ctime will be updated, so VOP_GETATTR() will succeed, but the ctime
check should be activated and the cache entry purged.
If the file on the server is unlinked or another file mv'ed on top of
it, its file handle should no longer be valid, so the VOP_GETATTR() call
should fail, which should cause the cache entry to be purged and a new
lookup RPC should be done.
What I find interesting is that in order for for open() to fail with the
ESTALE error, the cache entry must be used, which means that this
VOP_GETATTR() call must be succeeding, but for some reason another VOP
call after namei() returns is failing with ESTALE.
>> Here's the output of the script:
>>
>> #!/bin/sh -v
>> rm -f file1 file2
>> ssh -n mousie rm -f file1 file2
>> echo foo > file1
>> echo bar > file2
>> ssh -n mousie cat file1
>> foo
>> ssh -n mousie cat file2
>> bar
>> tail -f file1 &
>> sleep 1
>> foo
>> cat file1
>> foo
>> cat file2
>> bar
>> ssh -n mousie 'mv file1 tmpfile; mv file2 file1; mv tmpfile file2'
>> cat file1
>> bar
>> cat file2
>> foo
>> echo baz >> file2
>> sleep 1
>> baz
>> kill $!
>> Terminated
>> ssh -n mousie cat file1
>> bar
>> ssh -n mousie cat file2
>> foo
>> baz
>>
>> Notice that immediately after the files are swapped on the server, the
>> cat commands on the client are able to immediately detect that the files
>> have been interchanged and they open the correct files. The tail
>> command shows that the original handle for file1 remains valid after the
>> rename operations and when more data is written to file2 after the
>> interchange, the data is appended to the file that was formerly file1.
>
> By the way, what were the values of acregmin/acregmax/acdirmin/acdirmax and
> also the value of vfs.nfs.access_cache_timeout in your tests?
I'm using the the default values for
acregmin/acregmax/acdirmin/acdirmax.
% sysctl vfs.nfs.access_cache_timeout
vfs.nfs.access_cache_timeout: 2
> I believe, the results of your test patterns heavily depend on the NFS
> attributes cache tunables (which happen to affect all cycles of NFS
> operation) and on the command execution timing as well. Moreover, I'm
> suspect that all this is badly linked with the type and sequence of
> operations on both the server and the client. Recall, I was about to fix
> just *one* common scenario :)
Some of my test cases waited for 120 seconds after the rename on the
server before attempting access from the client, which should be enough
time for the attribute cache to time out.
> With different values of acmin/acmax and access_cache_timeout, and manual
> operations I was able to achieve the result you consider as "proper" above
> and also, the "wrong" effect that you described below.
>
>> And its output:
>>
>> #!/bin/sh -v
>> rm -f file1 file2
>> ssh -n mousie rm -f file1 file2
>> echo foo > file1
>> echo bar > file2
>> ssh -n mousie cat file1
>> foo
>> ssh -n mousie cat file2
>> bar
>> sleep 1
>> cat file1
>> foo
>> cat file2
>> bar
>> ssh -n mousie 'mv file1 file2'
>> cat file2
>> foo
>> cat file1
>> cat: file1: No such file or directory
>>
>> Even though file2 was unlinked and replaced by file1 on the server, the
>> client immediately notices the change and is able to open the proper
>> file.
>
> My tests always eventually produce ESTALE for file2 here. However, I suspect
> their must be configurations where I won't get ESTALE.
>
>> Conclusion: relying on seeing an ESTALE error to retry is insufficient.
>> Depending on how files are manipulated, open() may successfully return a
>> descriptor for the wrong file and even enable the contents of that file
>> to be overwritten. The namei()/lookup() code is broken and that's what
>> needs to be fixed.
>
> I don't think it's namei()/lookup() which is broken. I'm afraid, the name
> and attribute caching logic is somewhat far from ideal. Namecache routines
> seem to work fine, they just do actual parsing/lookup of a pathname. Other
> functions manipulate with the cached names basing on their understanding
> of the cache validity (both namecache and cached dir/file attributes).
I think the main problem is namei()/lookup(). They shouldn't be
returning a vnode that is associated with a file handle that points to a
different or non-existent file on the server if the name to handle
association has been invalid for a long period of time. While it's not
possible to totally enforce coherency, we should be able to do a lot
better.
> I've also done a number of tcpdump's for different test patterns and I
> believe, what happens with the cached vnode may depend on the results of
> the "access" RPC request to the server.
That may be an important clue. The access cache may be properly
working, but the attribute cache timeout may be broken.
> As I said before, I was not going to fix all the NFS inefficiencies related
> to heavily shared file environments. However, I still believe that
> open-retry-on-ESTALE *may* help people to avoid certain erratic conditions.
> At least, I think that having this functionality switchable with an
> additional sysctl variable, *may* help lots of people in the black art of
> tuning NFS <attribute> caching. As there are no exact descriptions on how
> all of this behaves, people usually have to experiment with their own
> certain environments.
>
> Also, I agree it's not the "fix" of everything. And I didn't even mention
> I want this to be integrated in the source :)
I don't think we can totally fix the problem, but I would like to see
the source fixed so that people don't have to patch their applications
or their kernel for common usage patterns.
> Actually, I know that it works for what I've been fixing locally and just
> asked for technical comments about possible "vnode leakage" and nameidata
> initialization which nobody provided yet ;-P
I think you're probably ok on the vnode side, but one problem might be
the flags in the struct nameidata. The lookup code tends to fiddle with
them. I was also concerned about leaking the cn_pnbuf buffer, but it
looks like it may not get allocated or may get freed in the error case,
since kern_open() don't call NDFREE(&nd, NDF_ONLY_PNBUF) if namei()
fails.
> I appreciate *very much* all of the answers, though. Definitely, a food for
> thought, but I'm a little bit tired of this issue already :)
>
> Thanks again for your efforts.
------------------------------
Message: 6
Date: Sun, 29 Jun 2003 19:22:42 -0700 (PDT)
From: Josh Brooks <us...@mail.econolodgetulsa.com>
Subject: per-directory quotas possible on 5.x ?
To: freebsd...@freebsd.org
Message-ID: <20030629191542...@mail.econolodgetulsa.com>
Content-Type: TEXT/PLAIN; charset=US-ASCII
Normally, quotas work on a per-user, per-filesystem basis - so if a user
has a home directory and other processes _not owned by that user_ are
placing files and using up space into that directory, it will not count
toward the quota (unless they get chowned/chgrpd to that user/group).
Is there any way to enforce a quota on a directory, regardless of what
ownership or group ownership the files and dirs inside the directory -
that is to say, take directory X, located at an arbitrary spot on the
system, I want it to grow no larger than size Y.
I know this can be done by creating a lot of little partitions - maybe
even vn-backed parttion-on-file, but that seems like a hack, as they would
be hard to resize.
I am looking for a way to force a changeable quota on a directory,
regardless of what gets put in it, or who owns what gets put in it.
Any hacks/asuggestions/comments of any kind are very appreciated.
------------------------------
Message: 7
Date: Mon, 30 Jun 2003 03:17:12 -0400
From: cisco-ns...@puck.nether.net
Subject: Your message to cisco-nsp awaits moderator approval
To: hac...@freebsd.org
Message-ID: <mailman.4.1056957...@puck.nether.net>
Content-Type: text/plain; charset="us-ascii"
Your mail to 'cisco-nsp' with the subject
Re: Application
Is being held until the list moderator can review it for approval.
The reason it is being held:
SpamAssassin identified this message as possible spam
Either the message will get posted to the list, or you will receive
notification of the moderator's decision. If you would like to cancel
this posting, please visit the following URL:
http://puck.nether.net/mailman/confirm/cisco-nsp/7c29c67e8edd10adbecc37c8fa862019478df0bb
------------------------------
Message: 8
Date: Mon, 30 Jun 2003 11:09:19 +0200
From: Paolo Pisati <p.pi...@oltrelinux.com>
Subject: [newbie] Allocating memory in kernel land
To: FreeBSD_Hackers <freebsd...@FreeBSD.ORG>
Message-ID: <2003063009...@southcross.skynet.org>
Content-Type: text/plain; charset=us-ascii
Hi guys,
as the subject says, i'm a newbie in kernel and
i'm facing the task to "port" a userland program
in kernel land (actually inside a netgraph node)
and i was wondering how to threat the memory inside
the kernel:
are there any important things i should be aware of?
like memory/stack limit, syscall, things thats shouldn't be,
and so on.
thanks in advance.
--
Paolo
GUFI: http://www.gufi.org
------------------------------
Message: 9
Date: Mon, 30 Jun 2003 11:29:42 +0100
From: Paul Robinson <pa...@iconoplex.co.uk>
Subject: Re: Fwd: Re: TODO list?
To: wg...@siue.edu
Cc: freebsd...@freebsd.org
Message-ID: <20030630102...@iconoplex.co.uk>
Content-Type: text/plain; charset=us-ascii
On Sat, Jun 28, 2003 at 06:52:36PM -0500, wg...@siue.edu wrote:
> I have taken a look at the PR list before, but I get depressed when I look at
> some of the requests. Some requests don't look very hard, but they require
> hardware that I don't have. How do you guys go about handling bug fixes if you
> don't happen to have certain hardware that someone else may have?
I was thinking about this the other day. And yes, it was frustrating. I just
went back and had another look at the list to see if there were any obvious
purges - and then something interesting popped up. There are quite a few
suspended or open PRs on older versions of FreeBSD, but nothing submitted
for later versions, and the problem seems to have "disappered" - e.g.
kern/2325 which was still a bug in 4.3-R, but I can't replicate in -CURRENT
(unless I'm doing something wrong). Which suggests somebody has fixed it.
Take a look at -CURRENT version of the relevant code, take a look at the
older version, if you can spot the problem, suggest an MFC? It might help
maintainers purge a big chunk.
Or you can just go around begging for hardware.
> Also, when you're working on a PR, do you roll your OS version back to whatever
> the PR requires? If so, do you just cvsup downgrade your source and "make
> buildworld... etc"?
I have VMware. I can have a copy of every -RELEASE and an up-to-date
-CURRENT on the go on the same machine all running at the same time if need
be. Expect performance problems. :-) Unfortunately it costs money and means
that for ease-of-use (trust me, the port is horrid) my main dev machine is a
Windows box, but even so...
> I have lots of interest in beginning some simple tasks with the kernel, but
> it's quite difficult to know where to start. I'm good at C/C++ and have taken
> an OS course; I just don't know how this particular kernel works on most levels.
I took a look at this aaaaages ago. Back in late 2001. My main problem then
was time. My current problem is getting bandwidth into my new home, but I do
know that PRs are a good way of learning the OS, gets you known to
maintainers, and ultimately helps purge a big, nasty database, everybody
wishes was empty. I also know that very senior members of the project will
give encouragement to anybody who helps purge PRs. My advice to you if you
have the time, is just go for it. I'll be finally getting around to my own
PR purging activities in a few weeks now that I have time, (soon!) bandwidth
and a desire to stop drinking. Long story. Don't ask. Anyway....
Good luck.
--
Paul Robinson
------------------------------
Message: 10
Date: Mon, 30 Jun 2003 11:40:43 +0100
From: Paul Robinson <pa...@iconoplex.co.uk>
Subject: Re: Questions
To: Edward Tiruvsky <radical...@hotmail.com>
Cc: freebsd...@freebsd.org
Message-ID: <20030630104...@iconoplex.co.uk>
Content-Type: text/plain; charset=us-ascii
On Sun, Jun 29, 2003 at 08:57:46AM +0000, Edward Tiruvsky wrote:
> i know this might be a long shot but ive got some questions and i was
> hoping someone could help me out or point me in the direction of someone
> who can...reply through the digest
<snip>
I think you've misunderstood the use of the word "hackers" in the context of
this mailing list. We have no interest in breaking into 3l337 w4R3z!! sites.
Nor do we need to blackmail anybody. Most of us have no need to conceal our
identities (although some still do - that's their choice). In short, we're
Unix hackers. Not security hackers. Even so, being a helpful sod, I'll give
you a pointer. *a - geddit??!?! Oh...
The answer to your question is yes, it is possible to chain re-mailers. Go
and do some research on anonymous re-mailers. The FAQs and manuals are full
of lots of good info on how to chain. Most of them do the hard work for you.
As for a secure webmail host - http://www.hushmail.com has worked for me in
the past. Quite good.
Oh, and now you've made the decision to hide your identity and make it
publically known, you know your phones will be tapped mail (snail and what I
call "normal") will be intercepted, your grandmother will get copies of
*those* pictures of you, and your life will now be a misery. And to make it
worse, you've just taken advice on protecting your identity from an
ex-civil-servant. Ho ho ho ho. We control the vertical. We control the
horizontal. Just sit back and relax. Relax... relax... many miles to go
before you sleep...
The poster regrets correspondance on this matter is now closed.
--
Paul Robinson
------------------------------
Message: 11
Date: Mon, 30 Jun 2003 15:57:51 +0400 (MSD)
From: Maxim Konovalov <ma...@macomnet.ru>
Subject: Re: TODO list?
To: Zak Johnson <zakj-freeb...@nox.cx>
Cc: freebsd...@freebsd.org
Message-ID: <2003063015...@news1.macomnet.ru>
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sat, 28 Jun 2003, 19:29-0400, Zak Johnson wrote:
> On 2003-06-28 20:27+0400, Maxim Konovalov wrote:
> > for instance?
>
> misc/25851
I am not familiar with sysinstall code, sorry.
> bin/32433
Fixed in -current.
--
Maxim Konovalov, ma...@macomnet.ru, ma...@FreeBSD.org
------------------------------
Message: 12
Date: Mon, 30 Jun 2003 15:26:00 +0200 (CEST)
From: Christopher Arnold <ch...@terrabee.net>
Subject: Re: TODO list?
To: Joachim Str?mbergson<watc...@ludd.luth.se>
Cc: freebsd...@freebsd.org
Message-ID: <2003063014...@home.terrabee.net>
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
On Sun, 29 Jun 2003, Joachim Strömbergson wrote:
> >>On Sat, 28 Jun 2003, 14:10-0400, Joseph Holland King wrote:
> >>>
> >>>this had a fix to begin with, and has a new fix now:
> >>>Re: kern/23173: read hangs in linux emulation
> >>>http://www.FreeBSD.org/cgi/query-pr.cgi?pr=kern/23173
> >>
> >>Assigned to maintainer.
> >
> > I'm not the maintainer, but I'll commit the patch in a couple of longish
> > minutes. An MFC will happen sometime next week. Feel free to ping me
> > at the end of next week if it hasn't been MFC'd by then.
>
> Pretty impressive, just by asking about how to contribute, Joshua Oreman
> have caused one commit of a fix from a PR and the closing of two other
> PRs. ;-)
Isn't it!
> Would it be productive/meaningful if one were to browse through the PR
> db, check/verify open PRs with fixes and report back to this list with
> "looks good" fixes so that they then could be commited in the same way
> as the three PRs reported by Joseph Holland King?
I have put some time into looking thru the PR db and there is a LOT of
stuff that either could be closed or could be fixed right away.
But i guess whats holding me back is the same thing that is holding others
back. Whats the correct way to get my hands dirty?
Is Joachim's idea of reporting back to -hackers correct? (I guess that
would be -ports for ports related issues?)
Some of the issues are quite fun. I mean how important is it that a
BusLogic unit dosn't work under FreeBSD 2.2.6? This is a five year old PR,
half the lifespan of the FreeBSD project... Couldn´t we close kern/7264?
If someone offers to be my mentor i would gladly walk thru the db and stir
up some dust. Any volonteer? I can even formulate my questions so you only
have to answer YES/NO...
If there isn't any volonteer i guess i just have to start pestering
everyone on -hackers...
/Chris
------------------------------
Message: 13
Date: Mon, 30 Jun 2003 16:43:27 +0200
From: Stijn Hoop <st...@win.tue.nl>
Subject: gethostbyname_r
To: hac...@freebsd.org
Message-ID: <20030630144...@pcwin002.win.tue.nl>
Content-Type: text/plain; charset="us-ascii"
Hi,
I was wondering if anybody was working on an implementation of a reentrant
gethostbyname_r function, mostly because it looks like mozilla/firebird will
finally gain support for an async DNS thread in the near future. However,
it is claimed in Mozilla's bug reporting system that FreeBSD 5.x doesn't
have support for this. See
http://bugzilla.mozilla.org/show_bug.cgi?id=70213#c36
A quick grep -r in /usr/src shows only hits in contrib, so it's probably
true that it's not implemented.
Any status?
--Stijn
--
The right half of the brain controls the left half of the body. This means
that only left handed people are in their right mind.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20030630/b4d9408b/attachment-0001.bin
------------------------------
Message: 14
Date: Mon, 30 Jun 2003 16:52:47 +0200
From: "Simon L. Nielsen" <si...@nitro.dk>
Subject: Re: gethostbyname_r
To: Stijn Hoop <st...@win.tue.nl>
Cc: hac...@freebsd.org
Message-ID: <2003063014...@nitro.dk>
Content-Type: text/plain; charset="us-ascii"
On 2003.06.30 16:43:27 +0200, Stijn Hoop wrote:
> I was wondering if anybody was working on an implementation of a reentrant
> gethostbyname_r function, mostly because it looks like mozilla/firebird will
This was discussed on the -threads mailinglist a few weeks ago. Try
looking at the achieves. I don't thin anybody is working on it at the
moment.
--
Simon L. Nielsen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20030630/aefd7236/attachment-0001.bin
------------------------------
Message: 15
Date: Tue, 01 Jul 2003 00:03:25 +0900
From: Hajimu UMEMOTO <u...@mahoroba.org>
Subject: Re: gethostbyname_r
To: Stijn Hoop <st...@win.tue.nl>
Cc: hac...@freebsd.org
Message-ID: <ygeisqnip4y.wl%u...@mahoroba.org>
Content-Type: text/plain; charset=US-ASCII
Hi,
>>>>> On Mon, 30 Jun 2003 16:43:27 +0200
>>>>> Stijn Hoop <st...@win.tue.nl> said:
stijn> I was wondering if anybody was working on an implementation of a reentrant
stijn> gethostbyname_r function, mostly because it looks like mozilla/firebird will
stijn> finally gain support for an async DNS thread in the near future. However,
stijn> it is claimed in Mozilla's bug reporting system that FreeBSD 5.x doesn't
stijn> have support for this. See
stijn> http://bugzilla.mozilla.org/show_bug.cgi?id=70213#c36
I believe Mozilla uses getipnodeby*() on FreeBSD. getipnodeby*()
calls do giant lock to expect thread-safe. So, I believe we don't
need gethostbyname_r() for Mozilla.
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
u...@mahoroba.org u...@bisd.hitachi.co.jp ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
------------------------------
Message: 16
Date: Mon, 30 Jun 2003 11:29:37 -0700 (PDT)
From: wp...@FreeBSD.ORG (Bill Paul)
Subject: Looking for RealTek 8169-based NIC for testing
To: hac...@freebsd.org, hard...@freebsd.org
Message-ID: <2003063018293...@hub.freebsd.org>
Content-Type: text/plain; charset=US-ASCII
I've decided to pick up one of the projects I let lapse some time ago,
which was to add support for the RealTek 8139C+ chipset to the rl(4)
driver. The 8139C+ is, by default, backwards compatible with the
8139A/B/C/D/etc... but also supports a descriptor-based DMA mechanism,
TCP/IP checksum offload, VLAN tagging and extraction, and TCP large
send. RealTek also has an 8169 gigabit ethernet chipset with almost
the same programming mechanism as the 8139C+, so I decided to support
that too.
However, while I have a sample 8139C+ NIC for testing, I don't have an
8169 gigE card. I can probably pick one up, but I don't know who sells
cards with this chip on it. If anyone can positively identify a card
that has uses this chip, i.e. from D-Link, Netgear, or whoever, I'd
appreciate it if you could point it me at it. If it's something that
can quickly be acquired from CompUSA, even better.
Note: RealTek also has an 8110 LOM (Lan On Motherboard) chip, which I
_think_ is register compatible with the 8169, however I don't want to
buy a whole new motherboard. Ultimately, I may need to find someone who
does have one of these so they can verify that the driver does in fact
work with it though, so if you've got one, save this e-mail and watch
for a call for testers.
-Bill
--
=============================================================================
-Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu
wp...@windriver.com | Wind River Systems
=============================================================================
"If stupidity were a handicap, you'd have the best parking spot."
=============================================================================
------------------------------
Message: 17
Date: Mon, 30 Jun 2003 14:39:07 -0400 (EDT)
From: Robert Watson <rwa...@freebsd.org>
Subject: Re: per-directory quotas possible on 5.x ?
To: Josh Brooks <us...@mail.econolodgetulsa.com>
Cc: freebsd...@freebsd.org
Message-ID:
<Pine.NEB.3.96L.10306...@fledge.watson.org>
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sun, 29 Jun 2003, Josh Brooks wrote:
> Normally, quotas work on a per-user, per-filesystem basis - so if a user
> has a home directory and other processes _not owned by that user_ are
> placing files and using up space into that directory, it will not count
> toward the quota (unless they get chowned/chgrpd to that user/group).
>
> Is there any way to enforce a quota on a directory, regardless of what
> ownership or group ownership the files and dirs inside the directory -
> that is to say, take directory X, located at an arbitrary spot on the
> system, I want it to grow no larger than size Y.
>
> I know this can be done by creating a lot of little partitions - maybe
> even vn-backed parttion-on-file, but that seems like a hack, as they
> would be hard to resize.
>
> I am looking for a way to force a changeable quota on a directory,
> regardless of what gets put in it, or who owns what gets put in it.
>
> Any hacks/asuggestions/comments of any kind are very appreciated.
Unfortunately, the UFS file system model makes it difficult to implement
this sort of feature. One major part of this is that files can exist in
more than one directory at a time, by virtue of hard links; this in turn
is relied on for file system checking, where a file may end up linked to
more than one directory when certain failure modes occur and are recovered
from. Another part of the problem is that the internals of UFS really
disassociate the namespace from the storage mechanism, and since such a
"directory based quota system" would determine the relationship between
files based on the namespace and not a per-inode attribute, this also
makes implementing such a system on a UFS file system difficult. FWIW,
you can sometimes get similar semantics using group quotas and the fact
that, on BSD, entries created in directories have the group of the parent
directory in which they are created...
Most of the systems I've seen that do quotas on a large scale do basically
follow the "many volumes" model -- for example, large AFS cells may have
tens or hundreds of thousands of volumes, and use volume size to impose
quotas, which sounds like what you're looking for. When I've seen things
like this done on UFS, it's usually been as a weak consistency accounting
mechanism -- measure the size of various trees at intervals and bill based
on the sampled size, rather than block allocation.
As you may have noticed in trying the vn-backed mechanism, there are some
inefficiencies that turn up in FreeBSD when have large numbers of
pseudo-devices, etc. The resizing problem is real, also, since we don't
have online file system resizing. FWIW, a file system like HFS+ (which
has a much more strict directory hierarchy) would lend itself to directory
quotas much more. A port of HFS+ to FreeBSD was recently posted to
freebsd-fs.
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
rob...@fledge.watson.org Network Associates Laboratories
------------------------------
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hacke...@freebsd.org"
End of freebsd-hackers Digest, Vol 15, Issue 1
**********************************************