Re: so where is our press-release about MacOS X ?
In message [EMAIL PROTECTED], Jordan Hubbard writes: I think you can assume that Jordan will veto me writing anything even remotely like a press-release for the project. I just thought it was a very good opportunity to beat the drum... I don't think you can assume any such thing - I say go for it! :) Well, how soon we forget history :-) Anyway, I barely have time to read my email this weekend so I'm out of the loop... One of the things that makes the Linux community as powerful as it is is the fact that so many people are involved in the advocacy side of things. Right, I fully agree. Chart me up in the "kernel architecture" category and lets find somebody else do the PR writing... -- 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: kern/23620: Fore PCA200E driver
In message [EMAIL PROTECTED], "Matthe w N. Dodd" writes: On Fri, 23 Mar 2001, Richard Hodges wrote: I hate to follow up on my own post, but I have not heard a word of comment, positive or negative... You're probably one of the few people that has the hardware to play with the ATM code in FreeBSD. This might account for your lack of feedback. Would you be interested in taking a more active role in maintaining the ATM code? I've got a couple of ATM driver related stuff on my TODO but it doesn't seem likely I'll get around to them any time soon. I can probably get away with sending a Fore and a efficient card to our new maintainer if we get one... -- 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: Displaying options for current NFS mounts
In message [EMAIL PROTECTED], Bruce Ev ans writes: On Sun, 25 Mar 2001, Peter Pentchev wrote: Only mount_foofs can reasonably know about the options for foofs. perhaps mount(8) could fork-exec mount_foofs(8) to print options for foofs. bikeshed type=question value="mostly stupid" Or could mount(8) invoke a couple of sysctl's to get a string representation of each mountpoint's mount options? /bikeshed My bikeshed believes that string processing doesn't belong in the kernel :-). I tore down my version of that bikeshed after I saw what kind of bogosities it resulted in. Sometimes ascii is the right API. -- 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
LonWorks anyone ?
Are there anybody out there playing with LonWorks and FreeBSD ? -- 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: # of bpf devices
In message [EMAIL PROTECTED], Dennis writes: It seems that only 256 bpf devices are supported. How painful would it be to increase that number...I assume its an 8bit varable somewhere? Are there other caveats? It's pretty trivial. Send a patch when you are done. -- 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: # of bpf devices
In message [EMAIL PROTECTED], Dennis writes: At 01:32 PM 03/28/2001, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Dennis writes: It seems that only 256 bpf devices are supported. How painful would it be to increase that number...I assume its an 8bit varable somewhere? Are there other caveats? It's pretty trivial. Send a patch when you are done. I was hoping to get some useful insight before I looked into it..or if there was a sound reason for not expanding them. Im hopeful someone brighter will answer. Well, if anybody but you had answered I would have fixed it right away, but since it would probably help you if I did so I morally can't defend to do it. I hope nobody else helps you either... -- 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: vm balance
In message [EMAIL PROTECTED], Matt Dillon writes: : :On Tue, 10 Apr 2001, Matt Dillon wrote: : :It's randomness that will kill performance. You know the old saying :about caches: They only work if you get cache hits, otherwise :they only slow things down. : :I wonder ... how does FreeBSD handle negative directory entries? : :That is, /bin/sh looks through the PATH to search for some executable :(eg grep) and doesn't find it in the first 3 directories. : :Does the vfs cache handle this or does FreeBSD have to go down into :the filesystem code every time? : :Rik The namei cache stores negative hits. /usr/src/sys/kern/vfs_cache.c cache_lookup() - if ncp-nc_vp (the vnode) is NULL, the cache entry represents a negative hit. cache_enter() - vp may be passed as NULL to create a negative cache entry. ufs/ufs/ufs_lookup.c, calls to cache_enter() enters positive or negative lookups as appropriate. You should also know that negative entries, since they have no objects to "hang from" and consequently would clog up the name-cache, are limited by the sysctl: debug.ncnegfactor: 16 which means that max 1/16 of the name cache entries can be negative entries. You can monitor the number of negative entries with the sysctl debug.numneg: 305 the value of "16" was rather arbitrarily chosen and better defaults may exist. -- 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: vm balance
In message [EMAIL PROTECTED], Matt Dillon writes: Again, keep in mind that the namei cache is strictly throw-away, but entries can often be reconstituted later by the filesystem without I/O due to the VM Page cache (and/or buffer cache depending on vfs.vmiodirenable). So as with the buffer cache and inode cache, the number of entries can be limited without killing performance or scaleability. Uhm, that is actually not true. We keep namecache entries around as long as we can use them, and that generally means that recreating them is a rather expensive operation, involving creation of vnode and very likely a vm object again. We can safely say that you cannot profitably _increase_ the size of the namecache, except for the negative entries where raw statistics will have to be the judge of the profitability of the idea. -- 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: vm balance
In message [EMAIL PROTECTED], Matt Dillon writes: : :In message [EMAIL PROTECTED], Matt Dillon writes: : :Again, keep in mind that the namei cache is strictly throw-away, but :entries can often be reconstituted later by the filesystem without I/O :due to the VM Page cache (and/or buffer cache depending on :vfs.vmiodirenable). So as with the buffer cache and inode cache, :the number of entries can be limited without killing performance or :scaleability. : :Uhm, that is actually not true. : :We keep namecache entries around as long as we can use them, and that :generally means that recreating them is a rather expensive operation, :involving creation of vnode and very likely a vm object again. The vnode cache is a different cache. positive namei hits will reference a vnode, but namei elements can be flushed at any time without flushing the underlying vnode. Right, but doing so means that to refind that vnode from the name is (comparatively) very expensive. -- 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: vm balance
In message [EMAIL PROTECTED], Matt Dillon writes: ::scaleability. :: ::Uhm, that is actually not true. :: ::We keep namecache entries around as long as we can use them, and that ::generally means that recreating them is a rather expensive operation, ::involving creation of vnode and very likely a vm object again. : :The vnode cache is a different cache. positive namei hits will :reference a vnode, but namei elements can be flushed at any :time without flushing the underlying vnode. : :Right, but doing so means that to refind that vnode from the name :is (comparatively) very expensive. : :-- :Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 :[EMAIL PROTECTED] | TCP/IP since RFC 956 The only thing that is truely expensive is having to physically scan a large directory in order to instantiate a new namei record. Everything else is inexpensive by comparison (by two orders of magnitude!), even constructing new vnodes. Without vmiodirenable turned on, any directory [...] It's worse than that, we are still way too rude in throwing away directory data... -- 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: vm balance
In message [EMAIL PROTECTED], Seigo Tanim ura writes: Those pieces of work were done in the last weekend, and the patch at Seigo http://people.FreeBSD.org/~tanimura/patches/vnrecycle.diff has been updated and now ready to commit. I'm a bit worried about the amount of work done in the cache_purgeleafdirs(), considering how often it is called, Do you have measured the performance impact of this to be an insignificant overhead ? Once we have that figured out I will commit the patch for you... -- 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: vm balance
In message [EMAIL PROTECTED], Seigo Tanim ura writes: Poul-Henning I'm a bit worried about the amount of work done in the Poul-Henning cache_purgeleafdirs(), considering how often it is called, Poul-Henning Do you have measured the performance impact of this to be an Poul-Henning insignificant overhead ? No precise results right now, mainly because I cannot find a benchmark to measure the performance of name lookup going down to a deep directory depth. Have you done any "trivial" checks, like timing "make world" and such ? It has been confirmed, though, that the hit ratio of name lookup is around 96-98% for a box serving cvsup both with and without my patch (observed by systat(1)). Here are the details of the name lookup on that box: Ohh, sure, I don't expect this to have a big impact on the hit rate, If I thought it would have I would have protested :-) For a more precise investigation, we have to measure the actial time taken for a lookup operation, in which case I may have to write a benchmark for it and test in single-user mode. I would be satisfied with a "sanity-check", for instance running a "cvs co src ; cd src ; make buildworld ; cd release ; make release" with and without, just to see that it doesn't have a significant negative impact. It is interesting that the hit ratio of directory lookup is up to only 1% at most, even without my patch. Why is it like that? Uhm, which cache is this ? The one reported in "vmstat -vm" ? That is entirely different from the vfs-namecache, I think it is a per process one-slot directory cache. I have never studied it's performance, but I belive a good case was made for it in the 4.[34] BSD books. -- 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: vm balance
In message [EMAIL PROTECTED], Seigo Tanim ura writes: Seigo http://people.FreeBSD.org/~tanimura/patches/vnrecycle.diff has been updated and now ready to commit. Ok, I ran a "cvs update ; make buildworld" here with and without your patch. without: 2049.846u 1077.358s 41:29.65 125.6% 594+714k 121161+5608io 7725pf+331w with: 2053.464u 1075.493s 41:29.50 125.6% 595+715k 123125+5682io 8897pf+446w Difference: + .17% -.18% ~0% 0% +.17% +.14% +1.6% +1.3% +15% +35% I think that means we're inside epsilon for the normal case, so I'll commit your patch later tonight. -- 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: vm balance
In message [EMAIL PROTECTED], Kirk McKusick writes: I am still of the opinion that merging VM objects and vnodes would be a good idea. Although it would touch a huge number of lines of code, when the dust settled, it would simplify some nasty bits of the system. When I first heard you say this I thought you were off your rockers, but gradually I have come to think that you may be right. I think the task will be easier if we get the vnode/buf relationship untangled a bit first. I may also pay off to take vnodes out of diskoperations entirely before we try the merge. Under the old name cache implementation, decreasing the number of vnodes was slow and hard. With the current name cache implementation, decreasing the number of vnodes would be easy. Actually the main problem is that NFS relies on vnodes never being freed to hold "soft references" using "struct vnode * + v_id). -- 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: vm balance
In message [EMAIL PROTECTED], Matt Dillon writes:
:When I first heard you say this I thought you were off your rockers,
:but gradually I have come to think that you may be right.
:
:I think the task will be easier if we get the vnode/buf relationship
:untangled a bit first.
:
:I may also pay off to take vnodes out of diskoperations entirely before
:we try the merge.
Yes, I agree. The vnode/VM-object issue is minor compared to
the vnode/buf/io issue.
We're getting there, we're getting there...
:Actually the main problem is that NFS relies on vnodes never being
:freed to hold "soft references" using "struct vnode * + v_id).
:
:--
:Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
I don't think NFS relies on vnodes never being freed.
It does, in some case nfs stashes a vnode pointer and the v_id
value away, and some time later tries to use that pair to try to
refind the vnode again. If you free vnodes, it will still think
the pointer is a vnode and if junk happens to be right it will
think it is still a vnode. QED: Bad things (TM) will happen.
# cd /sys/nfs
# grep v_id *
nfs_nqlease.c: vpid = vp-v_id;
nfs_nqlease.c: if (vpid == vp-v_id) {
nfs_nqlease.c: if (vpid == vp-v_id
nfs_vnops.c:vpid = newvp-v_id;
nfs_vnops.c:if (vpid == newvp-v_id) {
--
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: vm balance
In message [EMAIL PROTECTED], Matt Dillon writes:
:I don't think NFS relies on vnodes never being freed.
:
:It does, in some case nfs stashes a vnode pointer and the v_id
:value away, and some time later tries to use that pair to try to
:refind the vnode again. If you free vnodes, it will still think
:the pointer is a vnode and if junk happens to be right it will
:think it is still a vnode. QED: Bad things (TM) will happen.
:
:# cd /sys/nfs
:# grep v_id *
:nfs_nqlease.c: vpid = vp-v_id;
:nfs_nqlease.c: if (vpid == vp-v_id) {
:nfs_nqlease.c: if (vpid == vp-v_id
:nfs_vnops.c:vpid = newvp-v_id;
:nfs_vnops.c:if (vpid == newvp-v_id) {
:
:--
:Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
hahahahahahahaha.. Look at the code more closely. v_id is not
managed by NFS, it's managed by vfs_cache.c. There's a big XXX
comment just before cache_purge() that explains it. Believe me,
NFS is the least of your worries here.
Matt, you try to free vnodes back to the malloc pool and you will
see what happens OK ?
--
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: vm balance
In message [EMAIL PROTECTED], Alfred Perlstein writes: I thought vnodes were in stable storage? They are, that's the point Matt is not seeing yet. Note that I really don't care for using stable storeage as a hack to deal with this sort of thing. Well, I have to admit that it is a pretty smart way of dealing with it for remote operations, but the trouble is that it prevents us from ever lowering their number again. If Matt can device a smart way to loose the soft reference in nfs, vnodes can be a truly dynamic thing. -- 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: vm balance
In message [EMAIL PROTECTED], Matt Dillon writes: :In message [EMAIL PROTECTED], Alfred Perlstein writes: : :I thought vnodes were in stable storage? : :They are, that's the point Matt is not seeing yet. I know vnodes are in stable storage. I'm just saying that NFS is the least of your worries in trying to change that. The namecache can do without the use of soft references. The only reason vnodes are stable storage any more is that NFS uses soft references to vnodes. -- 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: Patch to make snp(4) devfs-friendly
In message [EMAIL PROTECTED], Dima Dorfman write s: Brian Somers [EMAIL PROTECTED] writes: This looks good. I'd say you should commit the change yourself - feel free to say it's reviewed by me. I'm not a src/ committer.. :-/ If you have a "reviewed by" an old hand like Brian, then it is OK for you to commit it yourself. -- 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: vm balance
In message [EMAIL PROTECTED], Matt Dillon writes: : :In message [EMAIL PROTECTED], Matt Dillon writes: : ::In message [EMAIL PROTECTED], Alfred Perlstein writes: :: ::I thought vnodes were in stable storage? :: ::They are, that's the point Matt is not seeing yet. : :I know vnodes are in stable storage. I'm just saying that NFS :is the least of your worries in trying to change that. : :The namecache can do without the use of soft references. : :The only reason vnodes are stable storage any more is that NFS :uses soft references to vnodes. The only place I see soft references on vnode is in the NFS lookup code which duplicates the VFS lookup code (except gets it wrong). If you are refering to the nqlease code... that looks like a hard reference to me. I'm not even sure why they bother to check v_id. The vp reference from an nfsnode is a hard reference. Well, if that's the case, yank all uses of v_id from the nfs code, I'll do the namecache and vnodes can be deleted to the joy of our users... -- 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: vm balance
In message [EMAIL PROTECTED], Kirk McKusick writes: Every vnode in the system has an associated object. No: device vnodes dont... I think the correct solution to that is to move devices away from vnodes and into the fdesc layer, just like fifo's and sockets. -- 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: vm balance
In message [EMAIL PROTECTED], Rober
t Watson writes:
On Wed, 18 Apr 2001, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Kirk McKusick writes:
Every vnode in the system has an associated object.
No: device vnodes dont...
I think the correct solution to that is to move devices away from vnodes
and into the fdesc layer, just like fifo's and sockets.
I dislike that idea for a number of reasons, not least of which is that
introducing more and more file-descriptor level objects increases the
complexity of the system call service implementation, and duplicates code.
If we're going to pretend that everything in the system is a file, and
most people seem willing to accept that, acting on devices through vnodes
seems like a reasonable choice.
I have not examined the full details of doing the shift yet, but it is
my impression that it actually will reduce the amount of code
duplication and special casing.
Basically we will need a new:
struct fileops devfileops = {
dev_read,
dev_write,,
dev_ioctl,
dev_poll,
dev_kqfilter,
dev_stat,
dev_close
};
The only places we will need new magic is
open, which needs to fix the plumbing for us.
mmap, which may have to be added to the fileops vector.
The amount of special-casing code this would remove from the vnode
layer is rather astonishing.
If we merger vm-objects and vnodes without taking devices out of the
mix, we will need even more special-case code for devices.
The vnode is our abstraction for objects that have
address spaces, can be opened/closed and retain a seeking position, can be
mapped, have protections, etc, etc.
This is simply not correct Robert, UNIX::sockets also have many of
those properties, but they're not vnodes...
Besides which,
the kernel knows how to act on vnodes, and there is plenty of precedent
for the kernel opening vnodes and keeping around references for its own
ends, but there isn't all that much precedent for the kernel doing this
using file descriptors :-).
Have you actually examined how FIFO and Sockets work Robert ? :-)
--
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: vm balance
In message [EMAIL PROTECTED], Matt Dillon writes: If this will get rid of or clean up the specfs garbage, then I'm all for it. I would love to see a 'clean' fileops based device interface. specfs, aliased vnodes, you name it... I think the aliased vnodes is the single most strong argument of them all for doing this... -- 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: vm balance
In message [EMAIL PROTECTED], Julian Elischer writes: If we merged vnodes and vm objects, then if devices were not vnodes, how would you represent a vm area that maps a device? You would use a VM object of course, but it would be a special kind of VM object, just like today... -- 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: vm balance
In message [EMAIL PROTECTED], Matt Dillon writes: :You can mmap() devices and you can mmap files.. : :you cannot mmap FIFOs or sockets. : :for this reason I think that devices are still well represented by :vnodes. If we merged vnodes and vm objects, :then if devices were not vnodes, how would you represent :a vm area that maps a device? : :-- : __--_|\ Julian Elischer I think the crux of the issue here is that most devices just don't need the baggage of a vnode and many don't need the baggage of a VM object except possibly for mmap(). A fileops interface would be the cleanest way to implement a wide range of devices. Lets compare our various function dispatch structures. It's quite obvious to me that we can merge cdevsw and fileops and remove all vnode references from most of our devices. Ok, maybe not /dev/tty... but most of the rest surely! We would also want to have an optional vnode pointer in the fileops (like we do now) which 'enables' the additional VOP operations on that file descriptor (in this case the fileops for read, write, etc... would point to VOP wrappers like they do now), and of course we would need an opaque pointer for use by the fileops (devices would most likely load their cdev reference into it). Right on. I think your table is wrong for "REVOKE", there is TTY magic in that. The fact that we have aliased vnodes for devices and for nothing else. The fact that all devices are handled by a magic filesystem (specfs) in the same "orphan" mode by all filesystems which support devices is another good reason. I think I'll kick back tonight and try to see what it actually takes to do it... -- 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: vm balance
In message [EMAIL PROTECTED], Matt Dillon writes: Actually, all this talk does imply that VM objects should be independant of vnodes. Devices may need to mmap (requiring a VM object), but don't need all the baggage of a vnode. Julian is absolutely correct there. Well, you have other VM Objects which doesn't map to vnodes: swap backed anonymous objects for instance. We do need to guarentee locking order, which means that all I/O operations should be consistent. If a device or vnode is mmap()able, then all read, write, and truncation(/extention) ops *should* run through the VM object first: We guarantee that today my mapping the actual hardware and my having all read/writes be synchronouse. I remember at least one other UNIX which didn't make that guarantee. -- 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: [OT] parallel port for IO?
In message [EMAIL PROTECTED], Warner Losh writes: If you have only 1 source, then you can use the ack line of the parallel port and the ppi driver to get timestamped events. If you have more than one, then you might be able to wire a simple latch to the ACK line and sample of to 8 sources. That's trickier as their's some hair in converting the signals to pulses, worrying about races, etc. 1 source gives you nanosecond resolution (but only ms accuracy due to interrupt latencies, us if you hack it to be a fast interrupt). Use the pps driver and you get microsecond jitter with nanosecond resolution. The pps driver implements the RFC2783 PPS-API for timestamping external events. -- 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: [OT] parallel port for IO?
In message [EMAIL PROTECTED], Warner Losh writes: In message 60546.987709317@critter Poul-Henning Kamp writes: : Use the pps driver and you get microsecond jitter with nanosecond : resolution. While I usually see microsecond jitter, I have seen it as high as a few milliseconds when the interrupt load on the machine was high and the cpu was slow. I setup a system for a user here for pps (pulse per second signal), and he was quite upset to see the occasional spike in his data. Fast interrupts reduced the occurance of spikes from a few an hour to one a day. The BIOS misuse of SMM mode can give you jitter in the 1msec range and there is not much you can do about it. I found out when I clocked a motherboard with a 14.318 derived from a Rb, and timed 1Hz pulses derived from a Cs. Every 400 seconds I ran into the SMM interrupt for about 10 seconds, and all my measurements were late by 800-900 microseconds :-( Intel doesn't care much for precision timing... -- 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: Idea for additional feature for jail - jailed security level
In message [EMAIL PROTECTED], Matt Dillon writes: I just had an idea... allow the kernel security level to be specified for a jailed environment. Add a 'securelevel' field to the jail structure and bump the API rev. That would be trivial to do, but I thought that securelevels were demed nice proof of concept but not the right way ? -- 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: BSDI and Marketing 101
In message [EMAIL PROTECTED], Dennis writes: At 01:06 AM 04/27/2001, Mark Sergeant wrote: I guess you missed the POINT, [...] And I have to hand that to you Dennis: when it comes to missing points you are the master... -- 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: x86-64 Hammer and IA64 Itainium
In message [EMAIL PROTECTED], Terry Lambert writes: Michael C . Wu wrote: I have been hearing about GaAs since the beginning of my college career. One chemistry professor put it rather well, Gallium Arsenide based semiconductors are considered the future of semiconductors, and always will be the future of semiconductors. Hitachi has a GaAs SPARC chip; it is used in Satellites. The CRAY-3 was GaAs based, if I'm not mistaken. And Convex made a GaAs based supercomputer, the 3800 I belive. -- 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: [jkh@osd.bsdi.com: ANNOUNCE: Status update on ftp.freebsd.org A KA ftp.freesoftware.com]
and whether this was to be a short-term or a long-term problem. With the release date for 4.3 already well publicized in advance and many people asking me for it, I decided to use one of our backup sites, the usw[1-6].freebsd.org cluster, and at least get the current releases bits up somewhere on an interim basis. Unfortunately, I really underestimated both the extent of the demand and the degree to which our big, fat Gigabit pipe at ftp.freesoftware.com has made distributing the bits to our mirrors look comparatively easy. Even with the login limits set *significantly* greater in favor of the registered mirror sites, and with multiple machines pulling the load, it quickly overwhelmed the new hosting infrastructure and resulted in significant bandwidth limiting on FTP traffic being instituted by the ISP. Even delaying the official announcement by 24 hours had no measurable effect on the overload since word of mouth and anticipation had already built demand beyond the saturation point. In short, what many of us have suspected for years turned out to be proven rather abruptly true: The FreeBSD.org services infrastructure has become overly reliant on resources which constitute single points of failure and lacks both sufficient tiering and redundancy in the face of such failure. We lost a key FTP resource and our entire distribution service essentially collapsed. The same may be true for CVSup, mail and WWW services and that's something we definitely need to look at. For now, the most critical item is to finish implementing the discussed-but-not-implemented ftp-master site scheme. A machine to serve as the project's master FTP host has been procured will shortly be available for FTP access. ONLY mirror sites will be allowed to connect to it, and it will always be pre-loaded with release bits, CERT advisories and anything else which requires the mirrors to have a head-start in advance of any public announcement. Announcements will only be made after a hand-inspection of the mirror sites reveals that a significant degree of propagation has taken place from the master site and not beforehand. What people currently regard as ftp.freebsd.org will become another tier of sites, probably served in round-robin DNS fashion, which have all agreed to meet the minimum requirements for being full and complete mirrors of the bits offered from ftp-master.freebsd.org. Existing mirror sites which wish to maintain only a subset of the master bits will become clients of these second-tier sites and subject to whatever distribution policies they institute. It would be my expectation that certain 2nd-tier sites will also have mirror access lists which favor the 3rd-tier sites over end-users, but that's a detail to be worked out over time. It's also not clear what, if anything, needs to be done to make sites like www.freebsd.org and hub.freebsd.org more reliable in the face of failure, but people can certainly expect that a good deal of thought will be going into answering those questions over the next few weeks. It certainly would have been nice to have had all of this been fixed before the release of 4.3, of course, and it's somewhat ironic that discussions about these very problems were occurring right around the same time, but it sometimes requires a truly painful experience to actually force an organization (or an individual for that matter) to both recognize and act on its shortcomings. The failure of the FTP site, the timing of FreeBSD 4.3 RELEASE and Wind River's acquisition of BSDi's BSD assets were simply unfortunate coincidences which had no causal link and I'd also be happy if people would stop inferring as much. Wind River has, in fact, indicated some interest in keeping the ftp.freesoftware.com site alive and we simply need to figure out the best way of doing so. As one might expect, a Gigabit connection and collocation facilities for a full 19 rack's worth of equipment doesn't come cheap! I will be releasing more information as the situation develops, both here and to the [EMAIL PROTECTED] mailing list. Thanks, - Jordan This is the moderated mailing list freebsd-announce. The list contains announcements of new FreeBSD capabilities, important events and project milestones. See also the FreeBSD Web pages at http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-announce in the body of the message - End forwarded message - To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3
Re: sysctl(8) and opaque MIB entries
In message [EMAIL PROTECTED], Sheldon Hearn writes: On 07 May 2001 18:51:22 +0200, Dag-Erling Smorgrav wrote: Yes it will, with -X. The interesting question is why there isn't an option to make it display just one variable in hex, and why it doesn't print a message when it omits printing an opaque variable. Do you think it'd be okay to allow an argument to -a and -A that specifies the sysctl node from which to descend? You mean like # sysctl vfs.devfs vfs.devfs.noverflow: 32768 vfs.devfs.generation: 116 vfs.devfs.inodes: 116 vfs.devfs.topinode: 118 :-) -- 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: Who's cleaning up after disk_clone?
In message [EMAIL PROTECTED], Dima Dorfman write s: disk_clone is set as the dev_clone handler by the disk minilayer to create /dev/disk0sXY devices; however, as far as I can tell, those devices are never destroyed. For example (/dev is devfs here): This is a subset of a larger problem: How to modules clean up properly. In this case it is slightly more complicated by the fact that the disk minilayer is involved. So, my questions are: - is this a bug? At least the page fault is; and Yes. - what should be destroying /dev/md0c? The disk-minilayer. We need some to keep track of cloned dev_t's so we can nuke them at various strategic points, havn't gotten to that yet. -- 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: telnet to AF_UNIX sockets [PATCH]
In message [EMAIL PROTECTED], James Howa rd writes: On Thu, 24 May 2001, Lyndon Nerenberg wrote: As a more general solution I have an inetd that groks AF_UNIX. You would have to add chroot/jail support to it, though, and some would argue that that's making inetd a bit featureful. Right, its *inetd*, not unetd (Unix net?:) Right, and just what was it the 'Inter' in InterNet referred to ? Interconnected Networks, that's what. And nowhere does it say that these nets can be running IP only... Let me remind you that inetd already does RPC based stuff, which for all practical intents and purposes is a separate protocol (at least it has it's own namespace, that's close enough for me) -- 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
http://phk.freebsd.dk/Gnats/
It seems that my little plot of our abysmal performance when it comes to our PR database actually helped spur some activity, at least the end of the graph points in the right direction now. But we are far from done yet, so find a couple of PR's and close them, there are 3000 to choose from... If you are not a committer, use the feedback mechanism (email or the link at the bottom of the webpages: http://www.FreeBSD.org/cgi/query-pr-summary.cgi If you think a PR can be closed, say so in your follow up with the grep'able line: This PR can be closed. Thanks in advance! -- 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: The design of the MD5 crypt() in FreeBSD
In message [EMAIL PROTECTED], Spike Gronim writes: I understand the literal meaning of /usr/src/lib/libcrypt/crypt-md5.c, and the algorithm it uses to create it's output. However, I do not understand the design criteria or functional purpose of several elements of the process. At the time the MD5 hash was written we could not use anything DES based due to ITAR. The design criteria was to get a strong, preferably stronger than DES, password encryption, which would make brute force attacks very much harder. At the time I had seen a demonstration of a bruteforce attack on a plain DES scrambled hardware which took less time than a good dinner to complete. The longer salt was to twart prebuilt dictionary attacks. With the 12 bit salt, an ExaByte tape could contain a *very* large precomputed dictionary, by increasing the salt-space several orders of magnitude this method was twarted. The overall MD5 chewing code were done to try to make the algorithm unsuitable for hardware implementation (MD5 is already pretty bad for that) the various unlinear steps would make it practically impossible to do a hardware implementation of anything but the basic MD5: you would still need to iterate through it. I don't know enough about cryptographic math to argue that this algorithm is perfect or even good. I know it to be better than the DES things, and infinitely better than the scrambler we had to fill the hole for DES at the time. In light of this theoretical backing, I introduced the $1$ marker, which allows the algorithm to be replaced in a backwards compatible way (as already done by OpenBSD). -- 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: MFC'ing new md(4) functionality?
In message [EMAIL PROTECTED], David O'Brien writes: On Mon, Jun 04, 2001 at 07:46:18PM -0700, Dima Dorfman wrote: Is there any reason not to MFC the new md(4) functionality Zero reason not to. Others see it differently, it would seriously break a lot of people who are using -stable in embedded applications. If we have abandoned the no changes to API or ABI in -stable paradigm, it would be a good idea, but it serious rains on that rule... -- 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: MFC'ing new md(4) functionality?
In message [EMAIL PROTECTED], David O'Brien writes: On Tue, Jun 05, 2001 at 06:33:17PM +0200, Poul-Henning Kamp wrote: Others see it differently, it would seriously break a lot of people who are using -stable in embedded applications. Can you expand on this? I assume you know we are not talking about disabling vn(4). We already have a previous form of md(4) in stable, -current's md(4) is not compatible with that older version. -- 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: MFC'ing new md(4) functionality?
In message [EMAIL PROTECTED], Ruslan Ermilov writes: On Tue, Jun 05, 2001 at 07:43:38PM +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], David O'Brien writes: On Tue, Jun 05, 2001 at 06:33:17PM +0200, Poul-Henning Kamp wrote: Others see it differently, it would seriously break a lot of people who are using -stable in embedded applications. Can you expand on this? I assume you know we are not talking about disabling vn(4). We already have a previous form of md(4) in stable, -current's md(4) is not compatible with that older version. And that older version doesn't even work (at least when loaded as the module): While true, it is not really relevant to the issue of API/ABI breakage in -stable... -- 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: MFC'ing new md(4) functionality?
In message [EMAIL PROTECTED], Dima Dorfman write s: Poul-Henning Kamp [EMAIL PROTECTED] writes: In message [EMAIL PROTECTED], David O'Brien writes: On Mon, Jun 04, 2001 at 07:46:18PM -0700, Dima Dorfman wrote: Is there any reason not to MFC the new md(4) functionality Zero reason not to. Others see it differently, it would seriously break a lot of people who are using -stable in embedded applications. If we have abandoned the no changes to API or ABI in -stable paradigm, it would be a good idea, but it serious rains on that rule... I don't think it would be much of a practical problem for anyone since the old behvior can be emulated with the new md pretty easily, but you're right that it isn't appropriate to break compatibility in -stable. It's probably possible to retrofit the old behavior into the new code, but I think that's too much evil for too little gain. Well, I see that we just ripped out the wd compat bits, so I guess we don't care about ABI/API stability that much in -stable any more... -- 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: import NetBSD rc system
In message [EMAIL PROTECTED], scanner @jurai.net writes: On Mon, 11 Jun 2001, Warner Losh wrote: In message [EMAIL PROTECTED] Doug Barton writes: : reason is that when you say System V anything, people have immediate : negative reactions that are based purely on emotion. S01My S02reactions S03to S04system S05V S06is S07not S08based S09purely S10on S11a S12pruely S13emotional S14reaction. S99Warner S100Amen! Which, maybe not by design, shows how butt-ugly the SVID /etc/rc system is... SVID /etc/rc, from the people who brought you the 32 bit namespace of SVID IPC... -- 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: cloning network interfaces
In message [EMAIL PROTECTED], Robe
rt Watson writes:
http://www.one-eyed-alien.net/~brooks/FreeBSD/gif.diff
has been updated. I'm still thinking about adopting the NetBSD
SIOIF{CREATE,DESTORY} interface.
An advantage to also supporting the ioctl interface is that it permits
interface cloning to be used on systems where devfs is not used, or where
there are parts of the system where devfs is unavailable (i.e., various
forms of chroots). I think devfs is cool and all, but given the existance
of fairly sensical non-devfs ways to do things, I'm tempted suggest
supporting them also.
As I already said: a device with no other precense in /dev has only
quickdirty reasons for using DEVFS cloning.
--
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: Patented algorithm in FreeBSD
In message [EMAIL PROTECTED], Mike Smith writes: Hi Go to http://www.uspto.gov/patft/, search for patent number 5873127, and you will find the description of mapping page table entries into virtual memory via one page directory entry pointing to the page directory itself - exactly what FreeBSD does with PTDPTDI and APTDPTDI entries on i386. (including using alternate space as in get_ptbase() in i386/pmap.c to access page table entries of different processes). It'd be hard to build a case on this patent, though; since it was granted in 1996, and the technique is as old as the hills, proving prior art would probably be relatively straightforward. Well, the application date is what counts, and that's mar1992, but I'm pretty sure that Bill Jolitz had them beat to that date already... -- 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
close a PR !!
Guys, We've been doing pretty well on the PR/Gnats front since we started our little Close a PR drive, but now is not the time to loose steam. http://phk.freebsd.dk/Gnats/ We're at the same level of unclosed PR's as we were half a year ago, down 500 from when we began the drive, but still 2653 to go... So please, everybody (committers and non-committers alike!) take a peek at the PR list here and close a couple of stale PR's for us: http://www.FreeBSD.org/cgi/query-pr-summary.cgi Committers close PR's with edit-pr on freefall. Non-committers by submitting a followup which contains an explanation and the grep(1)'able line: This PR can be closed Remember: Each open PR is a pissed off contributor... -- 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: Patented algorithm in FreeBSD
In message [EMAIL PROTECTED], Jordan Hubbard writes: From: Bill Vermillion [EMAIL PROTECTED] Subject: Re: Patented algorithm in FreeBSD Date: Wed, 13 Jun 2001 09:45:46 -0400 We just need to hide all the code from the lawyers. Why? They wouldn't understand it anyway. What we really need to do is stop HIRING them. :) You know, there is almost a fortune in that... -- 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: mount_mfs-like program for md
to mount the filesystem. XSee X.Xr mount 8 Xfor more information. X.It Fl p Ar permissions XSet the file (directory) permissions of the mount point X.Ar mount-point Xto X.Ar permissions . X.It Fl S XDon't enable soft-updates on the filesystem. X.It Fl s Ar size XSpecify the size of the disk to create. XThis only makes sense if X.Fl F Xis X.Em not Xspecified. XThat is, Xthis will work for the default swap-backed X.Pq Dv MD_SWAP Xdisks, Xand the optional X.Pq Fl M X.Xr malloc 9 Xbacked disks X.Pq Dv MD_MALLOC . X.It Fl w Ar user Ns | Ns Ar group XSet the owner user and group to X.Ar user Xand X.Ar group , Xrespectively. XThe arguments have the same semantics as with X.Xr chown 8 , Xbut specifying just a user or just a group is not supported. X.El X.Pp XThe X.Fl F Xand X.Fl s Xoptions are passed to X.Xr mdconfig 8 Xas X.Fl f Xand X.Fl s , Xrespectively. XThe X.Fl a , X.Fl b , X.Fl c , X.Fl d , X.Fl e , X.Fl f , X.Fl i , X.FL m Xand X.Fl n Xoptions are passed to X.Xr newfs 8 Xwith the same letter; Xthe X.Fl O Xoption is passed to X.Xr newfs 8 Xas X.Fl o . XThe X.Fl o Xand X.Fl t Xoptions are passed to X.Xr mount 8 Xwith the same letter. XSee the programs that the options are passed to for more information Xon their semantics. X.Sh EXAMPLES XCreate and mount a 32 megabyte swap-backed filesystem on X.Pa /tmp : X.Pp X.Dl mdmfs -s 32m md /tmp X.Pp XCreate and mount a 16 megabyte malloc-backed filesystem on X.Pa /tmp Xusing the X.Pa /dev/md1 Xdevice; Xfurthermore, Xdon't use soft-updates it and mount it X.Cm async : X.Pp X.Dl mdmfs -M -S -o async -s 16m md1 /tmp X.Sh AUTHORS X.An Dima Dorfman X.Aq [EMAIL PROTECTED] END-of-mdmfs/mdmfs.8 exit To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message -- 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: Query: How to tell if Microsoft is using BSD TCP/IP code?
In message [EMAIL PROTECTED], Wes Peters writes: Mark Valentine wrote: No. The core SpiderTCP protocol implementation is _not_ derived from BSD. [...] (NOTE: this was never sockets over TLI like the stuff some UNIX vendors bought from a Spider competitor!) *Cough*Lachman*cough*. *Cough*Wollongong*cough*hack*wheeze* (THUD!) -- 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: FreeBSD Mall now BSDCentral
In message [EMAIL PROTECTED], Sergey Babkin writes: If the FreeBSD Foundation is an existing entity now, maybe we can just change the license for the CD images to not for resale unless the distributor signs an agreement with the Foundation ? Why on _earth_ would we make it so hard for people to get hold of a media copy of FreeBSD, when absolutely nothing prevents me or anybody else from rolling a net distribution ? -- 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: FreeBSD Mall now BSDCentral
In message [EMAIL PROTECTED], Brian Somers writes: I'm not having a go at Cheapbytes. I'm just saying that their CDs should be labeled official or unofficial based on their content. If they want to drop the base ISO image onto a CD and sell it, then they're as official as anybody else. Right, and what are you going to do about some random company in Elbonia who labels and unapproved cd as Official ? One should never makes rules one can't enforce... -- 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: freebsd bios.
In message [EMAIL PROTECTED], Ronald G Minnich writes: So, I repeat: easily done, not acceptable to freebsd core. Uhm, Ron, I have not seen freebsd core take a stand on this, and I'm a core team member, so I'm pretty sure they havn't. I also doubt that they ever would do so. Remember: Nobody carries so much weight in the FreeBSD project that they can *prevent* somebody from doing something like this. If you or others feel this is worthwhile and interesting, you should just go work on it. You don't need to get "permission" from anybody. Don't get all upset because one or two people come across a bit grumpy on email. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | 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: freebsd bios.
The key is that freebsd may need to change a few things to make it bootable from cold hardware. I don't think this is for sure, but it may happen. I hope the team is receptive to such changes ... ie. "LinuxBIOS won't initialise the system correctly, so you'd better clean up after it"? How is the microcode loading handled in LinuxBIOS ? As far as I know getting hold of the microcode-supplemental data from Intel is a process which is (impossible - epsilon) and certainly not open source compatible ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | 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: Little Complain
So if one of the "high" people agree with this idea, I could set up such a system (well I have to look for a constant internet connection, but I suppose my ISP will give me one for free when his name is listed on the contribution list :-)). We don't need any "high" people to agree with this: Just do it, if it works, people will use it and it will become a success, if it doesn't work...well you can say that you tried :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | 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: ACPI project progress report
In message [EMAIL PROTECTED], Warner Losh writes: In message [EMAIL PROTECTED] Mitsuru IWASAKI writes: : Maybe I'm wrong because of lack of my understanding on crush dump and : loader. Please help us :-) I think that you might be able to do this. The real tricky part maybe saving hardware RAM that the drivers expect to be there when you wakeup. I thinking of video ram and the X server's font cache, to name one example. Drivers will need a "your hardware may have been zonked" entrypoint, think about the i8254 counter or all the weird versions of write only or "write here - read there" I/O registers in existence. Obviously the video driver will need to send a signal or clue to the Xserver saying "you own the device, you'd better do something" -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | 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: netgraph support for channelized LMC 1504 PCI card?
I have a card here, and I am making good progress, I have the framers up and running and am working on the HDLC controller. I expect to pass the first HDLC frames today or tomorrow. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | 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: Jails
In message [EMAIL PROTECTED], lists@se curity.za.net writes: Hi, Does anyone out there know of any patches available to let me assign more than one ip to a jail. Havn't heard about any. While on the subject of jails, just out of curiosity, is there any reason that I cant ping out of a jail even when Im root on the jail (it says operation not permitted?) Because implementation would be tricky (filtering raw IP packets) and nobody has done it yet. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | 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: if_de or if_dc?
In message [EMAIL PROTECTED], Dennis writes: I asked this on the hackers list and noone answered, so maybe some of the isps know? Why don't you spend some time testing it and tell us the result ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | 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: buildworld summary
In message [EMAIL PROTECTED], Ben Smithurs t writes: A few months ago someone posted a script that summarizes make buildworld as it progresses. I've searched the ports and the mailing lists but I can't find it any more :-( so I'd be grateful if someone would tell me. Thanks. =20 It was phk (cc'd), and yes, it seems to have evaporated. Hmm, are you sure you're not thinking of 'whereintheworld' by fenner, or isn't that what you were thinking of? Take a look at http://people.freebsd.org/~fenner/whereintheworld and see if it's what you're after. I also had a script, I'll try to see if I can find it again when I have time. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | 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: sys/ufs/ufs/ufs_quota.c
In message [EMAIL PROTECTED], "clemensF" writes: Marius Bendiksen: the various quota routines, rather than a (struct proc *). As I can see from the code, chkdq(), for example, should rather be using an suser() check upon a process structure, than testing cred-cr_uid==0. Are there any objections to changing this? this should be more portable and future-save, right? Isn't there an issue with NFS server side ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | 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: Periodic scripts [Was: Re: /etc/security - /etc/periodic/security ?]
In message [EMAIL PROTECTED], Nick Rognes
s writes:
On Fri, 30 Jun 2000, Fotis Georgatos wrote:
Why bother with complex shell scripts when you can have most
needed functionality in a single C program?
I've found myself replacing 10-20 lines of shell code with a single line.
WHAT? Are you crazy? I've found just the opposite.
What shell scripting are you using? Example to find # of
duplicate usernames in your password file:
#!/usr/local/bin/ksh
VAR1=`awk -F: '{print $1}' /etc/passwd|grep -cx $1`
print "Number of occurences of $1 in /etc/passwd: $VAR1"
Let me see you replicate that in C in less than 2 lines...
Nick, I can do it in one line, but it will suck style wise because I
cannot use #includes.
Can we stop this pissing contest now before anybody starts flouting
APL single-liners ?
Thanks.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | 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: invlpg produces strange sig11 on PentiumPro box
In message [EMAIL PROTECTED], KATO Takenori writ es: The invlpg instruction causes strange signal 11 problem on some PentiumPro box. This problem seems to hapen when (1) mother board is very old and (2) BIOS update is not available and (3) cpuid 0x619. Following patch automatically disables invlpg when PentiumPro with cpuid 0x619 is found. Please comment to this patch. I'm against this patch. This is so specific and marginal to a out-of-spec hardware configuration, that it should not be put in the FreeBSD tree. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | 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: invlpg produces strange sig11 on PentiumPro box
In message [EMAIL PROTECTED], Mike Smith writes: In message [EMAIL PROTECTED], KATO Takenori writ es: The invlpg instruction causes strange signal 11 problem on some PentiumPro box. This problem seems to hapen when (1) mother board is very old and (2) BIOS update is not available and (3) cpuid 0x619. Following patch automatically disables invlpg when PentiumPro with cpuid 0x619 is found. Please comment to this patch. I'm against this patch. This is so specific and marginal to a out-of-spec hardware configuration, that it should not be put in the FreeBSD tree. I'd disagree with that. This is just the same as the 0xf00f workaround, saving only in degree. If it's something that can be done as eg. a KLD we might want to do that instead, or through some other mechanism for handling these sort of CPU quirks. Please Mike, just because you see my name you shouldn't take a contrary positition until you have actually looked into matters. Look at the first paragraph: This is for Pentium Pro cpus running in motherboards where the BIOS does not contain the needed microcode updates. The patch disables invlpg on all cpuid's 0x619, despite the fact that they work just fine if your motherboards BIOS have the right microcode update for your cpu stepping. This hack should be maintained by the person who need it, it should not be lobotomizing FreeBSD in general. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | 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: invlpg produces strange sig11 on PentiumPro box
In message [EMAIL PROTECTED], Wilko Bulte writes: Maybe make it conditional via an option in the kernel config file? Off by default of course. Looking at LINT/NOTES I see very obscure things for Cyrix and Bluelightning CPUs already. But Wilko, Those hacks are because the silicon, when used as directed, has flaws. OK, I understand that. But it appears to me that this patch allows the use of Si that should have had it's problems correct by the BIOS but in fact has not (because a corrected BIOS is not available). I'm one of those people who prefer a built-in, docuemted, switchable patch/hack over one that needs to be hunted down on the Net and applied. Heck, if I wanted to do that I would have chosen Linux ;-) I'm sorry, but I still don't think this patch belongs in FreeBSD. What guarantee do you have that this is enough to make those CPUs run reliably anyway ? As far as I know Intel never released the errata which the microcode updates fixes anyway. I'm still against. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | 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: Why do we always create a malloc disk for md?
In message [EMAIL PROTECTED], John Baldwin writes: This ends up registering md1 with disk_create, and thus md1 is returned as a disk through kern.disks into the list returned by Disk_Names(), and sysinstall blows up when it tries to open it. I think the reason it blows up is because /dev/md1 isn't around, although I think I may be able to fix that by adding 'md' as a disk device in the table in sysinstall/devices.c.\ However, I'm curious if md1 should be created in this case? Your diagnosis is correct. sysinstall should ignore md* disks. The reason md1 is created is that it is the beginning of an "almost-clone" implementation. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | 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: invlpg produces strange sig11 on PentiumPro box
In message [EMAIL PROTECTED], John Baldwin writes: *ahem* You might want to read the first paragraph as well. It is for situations where one _can't_ update one's BIOS. I don't see why making it a tweakable kernel compile time know that is off by default would be so incredibly bad. We have precedents already for this type of thing. And yes, in this case, the CPU is not performing as advertised. So far we have set the limit at hardware being used correctly. Either way, this patch was not the correct way to fix this particular erratum. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | 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: mbuf re-write(s), v 0.1
In message [EMAIL PROTECTED], Bosko Milekic writes: I'm getting the unfortunate impression that evolution is being frowned upon here. Are their other people that frown the proposal out there to this extent? (i.e. "don't change it if it works") I'd like to hear some important voices on this issue so that I can decide whether to just drop this entire thing and forget about it. (in other words, what do committers and/or core have to say about this?) If you can improve it, and show it to be improved, I think it is a good idea. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | 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: mbuf re-write(s), v 0.1
In message [EMAIL PROTECTED], David Greenman writes: I'm getting the unfortunate impression that evolution is being frowned upon here. Are their other people that frown the proposal out there to this extent? (i.e. "don't change it if it works") I'd like to hear some important voices on this issue so that I can decide whether to just drop this entire thing and forget about it. (in other words, what do committers and/or core have to say about this?) Aside from this, I've gotten several other "pro" opinions on this; some people have even sent suggestions. So I know that I am not the only one (not by far, in fact) to see an opportunity to benefit from this. Either way, I know *I* will be using this code in time to come, so I suppose the question is: Would you consider committing this code or should I stop posting any changes I make in the future altogether? What I'm doing is challenging your assertions that spending CPU cycles to save memory in the networking code is the right thing to do. I'm further saying that I have direct experiance in this area since I'm one of the primary people in FreeBSD's history that have spent major amounts of effort in improving its performance, especially in the networking area. David, not all FreeBSD systems come with 128MB ram or more. We have a significant market of very small systems where a different policy might make a lot more sense. I agree that real numbers will have to be used to make any decisions however. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | 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: mbuf re-write(s), v 0.1
In message [EMAIL PROTECTED], B osko Milekic writes: When I posted the initial diff, I provided such data. I'll repeat: a good example is at: http://24.201.62.9/stats/mbuf.html Considering the prominence of DoS attacks and similar, I think it makes a lot of sense to be able to free the memory again, and if the hysteresis you have built in means that there is no measurable performance impact I think you will face no objections. Is it possible to auto-tune min_on_avail somehow ? What if instead you made it free only when more than 50% of the memory allocated from the map was unused ? Could that freeing be done by a timeout routine which runs every N seconds ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | 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: mbuf re-write(s), v 0.1
In message [EMAIL PROTECTED], Bill Fumerola writes:
I'd love to have FreeBSD be able to reclaim memory quicker at the sacrifice
of a few cpu cycles. Why? Well, the "add more memory" arguement doesn't work
well when I get DoS attacks that will eat any memory available because they
can connect quicker then I can reclaim the memory.
I have this dream of a global "VM availability flag":
Imagine if the kernel kept a global variable:
enum {VM_PLENTY, VM_TIGHT, VM_NONE, VM_PANIC} vm_state;
/* VM_PLENTY: No worries */
/* VM_TIGHT: Don't make it any worse if you can avoid it */
/* VM_NONE: Fail if you must, free some if you can */
/* VM_PANIC: "VM, VM, my panic for some VM" */
At least a few pieces of our memory-gobbling code could examine
and adjust their caching behaviour from that. Take the vfs
name-cache as an example:
/* Create a new vfs_name-cache entry */
cache_enter(...)
switch (vm_state) {
case VM_PLENTY:
/* do as today */
break;
case VM_TIGHT:
/* delete at least as many bytes as we add (LRU wise) */
break;
case VM_NONE:
/* delete two entries, don't add the new one */
break;
case VM_PANIC:
/* delete the entire cache */
break;
}
The mbuf allocator can use this to great effect if the various
MGET() calls were labeled according to their importance.
Respecting such a flag in the various kernels provide great resistance
against DoS.
User land processes can benefit from this as well: a sysctl would
allow malloc(3) to investigate this state whenever it had was
dealing with a full page, and if needed it could release all it's
cached pages, possibly even call an optional "GC" callback into
the program to force a realloc(3) sequence in long-running daemons.
(An alternative scenario is to have a SIGVMSTATE defaulting to
ignore which gets sent when the variable changes, but that would
have thundering herd issues if a lot of processes was paged out.)
If only somebody would add that variable, I don't feel like diving
into the VM system right now.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | 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: Global variables defined several times.
In message [EMAIL PROTECTED], David Malone writes: I've just noticed that usr.bin/ftp/ftp_var.h defines a large selection of global variables, and then this header file is included in multiple C source files. I thought this should lead to one copy of the global varible per source file, and then a warning or error at link time due to symbols being defined multiple times. This doesn't seem to be the case with the toolchain - you seem to get one copy of each variable for the final linked unit. This is called "common" variables. They're documented with that behaviour in the old and new testament. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | 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: Module parameters?
In message [EMAIL PROTECTED], "Gary T. Corcoran" writes: No, I know it's not that easy. We need to be able to do things like have "TransmissionMode=4" on the kldload command line, and have that parse the decimal value 4, and then go into the module and set the value of the TransmissionMode variable to actually be 4 immediately after loading the module into memory, before any of its subroutines are called. This is what the Linux module loader allows, and it's extremely useful... I have a much simpler idea: The loader needs to pass an argc+argv to the modules "configure" routine, and the module can do whatever it damn pleases with the passed arguments. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | 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: DEVFS
In message [EMAIL PROTECTED], Coleman Kane writes: Who is currently working on the DEVFS? I emailed the last person to commit to the HOWTO and got no response. I'd like to look into finisheing this, and may start hacking if no one tells me otherwise... bp@ has a non-working prototype, (as has julian@). None of them fixes the root-mount kludges. None of them implement cloning devices. If you (or a group of people) seriously want to work on DEVFS, send me an email and I will coordinate and try to make sure we get this done *right* so that we cover all the issues we need to cover with devfs (root-mount, jail, cloning etc etc) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | 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: DEVFS
None of them fixes the root-mount kludges. actually the code you and SOS delted DID solve that No it didn't. rootvn was still magically wired from rootdev, with DEVFS mounted first it could be looked up with namei in a proper fashion. None of them implement cloning devices. no, though have you tried looking at ptys under devfs.. as you use them, more are created.. (a bit of a hack but kinda cute). Cute, but not cute enough. We have several devices which do this by now, but we need full cloning ability. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | 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: sysctl interface for apm?
In message [EMAIL PROTECTED], [EMAIL PROTECTED] wri tes: So what does everyone think? Is it suitable to add a read only sysctl 'machdep.apm_powerstate' that reports either AC, nn%, or N/A ? Or should the format be numeric (999 = AC, =100 = battery %, -1 = N/A)? Or should we not bother? :-) yes it is suitable. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | 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: /etc/security - /etc/periodic/security ?
In message [EMAIL PROTECTED], Alexander Langer writ es: Thus spake James Howard ([EMAIL PROTECTED]): fairings? Why does it matter what color the bikeshed is? What does What is this thing with the bikesheds??? It appears on every place I am, on IRC, now here. As a non-native English-speaker, I'd like to know what's up with the poor bikesheds. The poor ones :-( It's a reference to a particular apt description of how committees work and don't work from the excellent book: Parkinson's Law C. Northcote Parkinson Buccaneer Books ISBN 1-56849-015-1 -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | 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: DEVFS
In message [EMAIL PROTECTED], Coleman Kane writes: Just to make sure we all know what's going on: Is someone currently tracking this thread and merging ideas into a write-up of what features DEVFS should have, as well as its implementation? I consider myself the coordinator for DEVFS, and I track the discussion and ideas that are floated. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | 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: Multiple ro mounts of vinum volume
In message [EMAIL PROTECTED], Bernd Walter writes: The point I never digged deeper here is because you already sugested changing the driver layer to 64bit byte numbers which was accepted if I remember right. Yes, I have this on my plate. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | 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: Device major number request for ACPI device.
In message [EMAIL PROTECTED], takawata@shidahara 1.planet.sci.kobe-u.ac.jp writes: Hi, I want major number for ACPI device. I will use the device interface to enable/disable ACPI and access to switches defined in ACPI. I have allocated major 152 for ACPI. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | 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: /tmp on a ramdisk?
In message 41777.964992152@localhost, "Jordan K. Hubbard" writes: MD has supplanted MFS, it doesn't run in conjunction with it. Just consider MD the new name for MFS if it makes it easier. Not *quite* true. MD and VN has supplanted MFS. For "boot with this ram-disk" it's MD, for "put my /tmp on ram/swap" it's VN. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | 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
How to make *real* random bits.
Ok, some people just can't leave an open end dangling (people like
me for instance :-)
I located a surplus german geiger counter cheaply [1], I have always
wanted to have one anyway, and in my junkbox I already had an old
smoke alarm [2]. The Geiger counter has a thin-walled tube which
takes about 15 events per second from the Am-241 source in the
smoke alarm.
The earphone output of the geiger counter with a 1kOhm load generates
a nice TTL level pulse which can be fed onto pin 10 of the parallel
port and timestamped with the PPS-API device ("device pps").
I think the parallel port could even power the geiger counter so that
batteries would be a non-concern.
Random bits are bits where no possible estimation of the next bit
is possible.
Entropy bits are bits which it may be possible to estimate with
a degree of uncertainty which is better than the statistical
average.
If I generate true random bits it takes 3 timestamps to get one
bit of randomness:
T1: Time of event 1
T2: Time of event 2
T3: Time of event 3
if (T2 - T1 T3 - T2)
return 0;
else if (T2 - T1 T3 - T2)
return 1;
else
try again.
In my rather crude setup it produces about 5 bits per second [3].
If the goal is to only provide entropy for a RNG (like Yarrow) we
can get much more mileage from the same number events: if the
average event rate is N events per second we can get roughly
/ T \
| timecounter |
log2| - |
\ N/
2
bits of entropy per event, which in my case (233 MHz and 15 events
per second) gives 12 bits per event or 180 bits of entropy per second.
Not bad...
Poul-Henning
[1] At "http://www.Helmut-Singer.de/" Called "FH40T Satz 2".
[2] Has to be an "ionization" type, otherwise it doesn't contain
the Am-241 alpha particle source.
[3] Feel free to analyze:
begin 644 random.bin
M8E6*C@L`HFII:/C=-8"7J).)`QC4H_`_3YM9W8?JB5,!1SZ%48PN48E
MN]!*;VTMLK\FKH@@6QWJ6JF=01Z:V(*5C?VA_LN[47$*CDOTDMA-8T0-::2D
M`_7L5'-8#GGOSV%X..@NQR"G3WV]I;"%7UKC(T[2]+UCAN:UMZ,_3]ZY
MR=#K6QCE%H8-@34$03"$!?!PT'LQ\)BP[61HP1$5IH"_CF]5=;EENALI8Z
M2'W`9Q-@AQ]UD.ZBONLN['"-9(]+D'/%R:MTQ,LKS8496,W@P$?ZC0!@.+
MMW=LM)\61/__+]EU3#8F1.2X6INC$^92%'T3VJ4?O%Q$)O/\R:+'G`F/!0K
M="/`F4AB'6["JQ]3=J%#^\S8DE]X-.S:_B=MT[4!#;RK.@K_U.*=]Q
MXM\_JVBHT9DEAM8+9@@4`MA[_3W:;"LCA/%W=0;5_K8(I6E\TXD"FY*WC
M4T";DDT,2D#E06D9A*FGR*6_MD#C:Z""_D#4#H-9#VC-W(X"MS50Z:R7N=
M,PW!A!$=YQ*D;P*$J$=2P4\$NYR_Y4KD[FG(OEW!U,31-NZM]3:B!9"?UX]
MR_X\O-C]ZO7R-"WTSHK7!("5CU4;3AE_:5,`1Z^?@M20N^!AI\MJ'3VBP3
MZ(2S^]MGDMA?8QO#WQV\,N_IX"6,6*BM']?IV=$!-5ATDCJHH"AF*GW
MZR?.7.\-_LO6PQVU4+F%)=NBV!9*ZBO(`V/66\+ZYM;(FX5TV'.=4MHOC;
M.IU*B([(\^ILO3NE6H,PC#PS:40CUI`'ZK)+N@$)62[/CW'=-W0HJ9]'T0
MCJ?D))W?.N.`1M?%\5ZFIBST0\YX!V!4-[[0_J+0.6+WWBG6@H?XXE
MO\W)$';`8KECLNU1DJ7E-ZDAG^67Y.`5;D"ZJQ)#;_=L*!A+DI..GC\V6
M1V#^G;0;LH+LVON9/EO43D3=.NW_5V?8M=EX5RL3:WT6R?RL1N67].KU!;,C
MN0QQ_E3*KH,10T::_,FM@LPPATIH+Y69;J7BURX@3E8#34_)98)C9;HK+
M?O3"JWA#-_Q5+@O$'M)\FY'[M61XUWZ+E*/_3WW0(=Y^T4+H@V\3AEFE=S#
MQJ%H=OD:[EMAIL PROTECTED](3D0^X'K@')[HPH!OLRG72!5E8M*9D'QB#ZO.!UF.K9
MPC`0.(6#S=P#2.3LV4:W=[TZPK42)RR5`:8\4R8M#M#7,Y:V6.J`+WQ-8$
M?$-R*K'B^*7.8VR3`+A!C*O5U0M%X$VT!?L1A#K,L8_\`F^'SH=:(2C,MU9
M;.Q@(4;'^0='82?6\57+1/,'?%4R./'AKXJR1Z8CCA`,#+PTS_+M?7
MT8Y2]4"2JVL4#GTLBO$8O1A:IS`:+'2'XB[%DH6;M4H+GGBV6N#\:A;
M:,:#T^BTD0F^=)=`AWQ1^Z5XI*M^3/]!9[:;W?'(O=5W]GCW=7%RAF?6,A!
M"PXR$.APB7,NN_,T54-W-J+SN,^B,B6TMH6!QY58Q/HAY(-"*CQ;9I6`G%
MQ!'#PNSH?;DX63R_#P,#C7:!PK.\;0%2)Q@-*?S"S)$@-!L1]1;*/)N,3
MBJE:!%O^TDY9PKUQ'Z?,A)QX)WGK7G6M5.5[I!2\/E%U7Q6"?YE/@25R
M#WIWAGKIG*Q:`P`-J$J2`:],J?.!'1K;XS1\7GL/XY$7BR(?^N,/\INW%H
M0OE'_\N/FR5",5!/%'I^^X#NO"2+24NWVUNVA.@WO^S)0@2`OKL,U8B#`4(
MR8(!DK(\XR00M4U/"2N62,)\!#K@6\+V#6Q;^?L++U;XBU"5=KH+S/
MZ'$S[7W0(/^,;8/3QDP$R?"+DH2'ZEJN;E(-6IXEZL'HZLY44IV$YU-^PAA
M-Z]O[1]U:+7MBF(G!Y49"7RX[X.!C#NFY,T:2E;6GS)RE;(8I0XA?_AR%
MJYR*,H0X%@G]P,,2JO%-V2`O+H@IKOK"$/7V7_:*6E%Y#OH!'[]5R';
M+YCB;()T?(IPUV*2)QKD)FUON5B4.1".\^@A_M4#FRRY2\U=*1[7Z%
M)]\,L,U;H08)(I";*TF)2*LU+T#L:MY?,T":X7R!V!U$K\OY:9"!KK61
M=?D)PJ4#DVV9X.O(\^KC*H\:FR08-!+4(V?K:1$9'G%.TN%(GG9#S%?4P88C
MDS/,.;H':!1/5%NV55/6H6*QX0U-(-+XA,GU]AB/H#-Q?VVW!UEY+?
M^9BD@;21+]:QLCGU/QD$+58RQ9$B!!:SD9UOA=;#6=*C1G#7\*_!M7'E\
M8%6XS6LN*F(_.)T0]:F?([`VOF-:9?KN`=XSH(KA`.-27(2G+[2H/NG75
MM!=N`V]S\X@SE@3@:6*75I$H1%8L(7\1BI6_(,$N56J!7J=R-4**[Y]HI!3
MN4VFY3JRK9/K"_W@S5FK$B,M?[$_4ET_@-7;'7B\5##I2,^63/WHUC:
M`89];@`QDUP+HK`?A.V@;Y:;KW(:'F$.@E9Y(3)!MX)W$-G/HA+8E/O
$).(Z[@`
`
end
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | 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: How to make *real* random bits.
In message [EMAIL PROTECTED], Matthew Seaman writes: Poul-Henning Kamp wrote: Ok, some people just can't leave an open end dangling (people like me for instance :-) I located a surplus german geiger counter cheaply [1], I have always wanted to have one anyway, and in my junkbox I already had an old smoke alarm [2]. The Geiger counter has a thin-walled tube which takes about 15 events per second from the Am-241 source in the smoke alarm. Nice. If you're thinking about this a possible commercial product, I wouldn't even dream about it :-) Perhaps there is a cheaper alternative as a good source of random bits. There are many ways to get random bits, this was just meant as an example that it doesn't have to be hard or even difficult to use FreeBSD for "special tasks". I'm pretty sure that "noise-diodes" are probably the most efficient way to generate random bits, but it doesn't measure up to a geiger- counter when it comes to "geek value" :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | 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: How to make *real* random bits.
In message [EMAIL PROTECTED] e, Paul Herman writes: But, if you are gathering a geek lobby to convince Intel to have an onboard geiger counter, you just might have a new member ;-) "Cesium-137 inside" Yeah, it does have a ring to it, doesn't it ? :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | 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: How to make *real* random bits.
In message [EMAIL PROTECTED], "Jonathan M. Bresler" writes: http://www.fourmilab.ch/hotbits/ Yup, that's where I got the idea. Difference is that I interface the geiger directly to a UNIX system, he has all sorts of magic stuff in the middle... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | 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: Fine grain timer
In message [EMAIL PROTECTED], Yingf ei Dong writes: hi, folks, I am revising a driver for a network interface. I need have a fine-grain timer (33us). Could anyone tell me how to get it? You will have to use DELAY(33). -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | 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: How to make *real* random bits.
In message [EMAIL PROTECTED], Warner Losh writes:
In message [EMAIL PROTECTED] Poul-Henning Kamp writes:
: The earphone output of the geiger counter with a 1kOhm load generates
: a nice TTL level pulse which can be fed onto pin 10 of the parallel
: port and timestamped with the PPS-API device ("device pps").
How does the variable, but somewhat predictable, latency of the
parallel port interface interrupt?
It cancels out since it is the same for all three events. Of course
if you raise the event density so that the interevent interval gets
into the same range as the interrupt jitter you have trouble, but
with ~15 events per second I'm not even close to that.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | 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: FreeBSD belly up with big config
In message [EMAIL PROTECTED], Dennis writes: With 1800 interfaces in the system Freebsd seems to use about 50Mhz of cpu when idle in "interrupts" even when there are no interrupts to process. on a 500Mhz box it uses 10% of the cpu and it seems linear with different speed processors. the 1800 interfaces are 900 DLCIs on a T3 frame with 900 bridge groups (rather common for a DSL delivered via Frame). This with just one line...the same problem could occur with say 8 T1 lines with 100+ DLCIs on each. It seems that there is substantial overhead just scanning interfaces for some routine maintenance...is there any hope of alleviating this deboggle? Sure: send us your patches! -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | 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
mhn, sendmail laptop at large...
The only way I can get sendmail to accept emails from nhm when my
laptop is InterNet challenged is by applying this patch to sendmail.cf.
nhm connects to sendmail on port 127.0.0.1:25 and sendmail complains
that it cannot look stuff up in DNS.
The way I see it, these two checks are reversed from the logical
sequence, but when I tried to explain this to Eric he said my config
was "wrong somehow".
Can anybody tell me the right way to make this work ?
Poul-Henning
--- freebsd.cf Fri Aug 4 23:33:30 2000
+++ /etc/mail/sendmail.cf Thu Aug 10 10:40:14 2000
@@ -15,9 +15,9 @@
#
# SENDMAIL CONFIGURATION FILE
#
-# built by [EMAIL PROTECTED] on Fri Aug 4 23:33:30 CEST 2000
-# in /freebsd/src/etc/sendmail
-# using /freebsd/src/etc/sendmail/../../contrib/sendmail/cf/ as configuration
include directory
+# built by [EMAIL PROTECTED] on Mon Jul 31 11:32:29 GMT 2000
+# in /usr/src/etc/sendmail
+# using /usr/src/etc/sendmail/../../contrib/sendmail/cf/ as configuration include
+directory
#
##
##
@@ -1005,6 +1005,9 @@
RRELAY $*$@ RELAY
R$* $* $: $2
+# anything originating locally is ok
+R$*$: ? ${client_name}
+
# allow relaying for hosts which we MX serve
R$+ @ $*$: : $(mxserved $2 $) : $1 @ $2
R : $* TEMP : $* $#error $@ 4.7.1 $: "450 Can not check MX records for
recipient host " $1
@@ -1018,8 +1021,6 @@
R? $+$@ OK
R$+ $* $: $2
-# anything originating locally is ok
-R$*$: ? ${client_name}
# check if bracketed IP address (forward lookup != reverse lookup)
R? [$+] $: BAD [$1]
# pass to name server to make hostname canonical
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | 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: limit processes that a user can 'see'
In message [EMAIL PROTECTED], Maxime Henrion writes: Hello, I have an idea that I would love to see applied in FreeBSD source code, but as I'm not skilled enough to code it, I post it to see if you think it makes sense, and if someone would be interested in coding this. It is a security measure regarding 'ps' command. By using the 'ps' command, any user logged in the system can view all the running processes, including root's one and processes of other users. My idea is to limit a bit this behaviour. You can possibly make jail(8) do this for you... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | 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: code question...
In message [EMAIL PROTECTED], "Chris Ptacek" w rites: I am getting a warning from a program I wrote: lined in free(): warning: chunk is already free. Is there anyway I can figure out where exactly this is happening, maybe cause a core or something. ln -s A /etc/malloc.conf run your program again... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | 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: sysctl from kernel
In message [EMAIL PROTECTED], Maxime Henrion writes: Hi, I'm new to the FreeBSD kernel and I wanted to know what are the good methods to read a sysctl value from the kernel. Is it the same interface as in user-space ? Any help or links to some documentation would be greatly appreciated :) Look at the kernel_sysctl() function in src/sys/kern/kern_sysctl.c -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | 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: sysctl from kernel
In message [EMAIL PROTECTED], Maxime Henrion writes: Thanks for your help ! If someone would be kind enough to answer them, I have a few other questions. I'm currently trying to modify sysctl_kern_proc() function in src/sys/kern/kern_proc.c First: look at sysctl(3) sysctl can read and set variables, so you pass it the "new" value and a buffer for the "old" value. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | 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: Tagged queuing for ATA drives, patches up for testing
I've put the latest patches for tagged queueing on ATA disks up for ftp on: ftp://freebsd.dk/pub/ATA/ATA-tagged-queueing-diff-0831.gz On my testmachine: atapci0: VIA 82C686 ATA66 controller port 0xffa0-0xffaf at device 4.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 ... ad0: 17206MB IBM-DJNA-371800 [34960/16/63] at ata0-master UDMA66 ad1: 14664MB IBM-DJNA-351520 [29795/16/63] at ata1-master tagged UDMA66 If I enable it on ad0, without without enabling it on ad1 it chokes. ad1 seems to be stable. Is there any way to read the firmware rev on ATA disks ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | 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: Tagged queuing for ATA drives, patches up for testing
Of course I should have done a "boot -v" (thanks neph!) Doesn't work with tagged queueing: ad0: IBM-DJNA-371800/J78OA30K ATA-4 disk at ata0-master ad0: 17206MB (35239680 sectors), 34960 cyls, 16 heads, 63 S/T, 512 B/S ad0: 16 secs/int, 0 depth queue, UDMA66 ad0: piomode=4 dmamode=2 udmamode=4 cblid=1 Works with tagged queueing: ad1: IBM-DJNA-351520/J56OA30K ATA-4 disk at ata1-master ad1: 14664MB (30033360 sectors), 29795 cyls, 16 heads, 63 S/T, 512 B/S ad1: 16 secs/int, 31 depth queue, tagged UDMA66 ad1: piomode=4 dmamode=2 udmamode=4 cblid=1 -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | 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
looking for microuptime went backwards victims...
I'm looking for the remaining victims of the dreaded "microuptime
went backwards" message.
If you can reliably reproduce the problem, please contact me, so
we can arrange for some very detailed tracing to try to find out
what exactly is going on. I have not been able to trigger the
problem in my lab in a long time.
If you see the message only occationally, please try the attached
patch and let me know if this changes the picture. The patch is
not meant as a fix, but it might reduce the impact of this condition
considerably when it happens. Basically by reducing the width of
the timecounter the magnitude of the hit we take if the timecounter
goes backwards is reduced from about an hour to approx 110msec.
Reducing the width to less than 17 bits starts to run the risk of
ambiguity due to clock rollover.
This patch may not be safe with PCAUDIO.
Poul-Henning
Index: clock.c
===
RCS file: /home/ncvs/src/sys/i386/isa/clock.c,v
retrieving revision 1.155
diff -u -r1.155 clock.c
--- clock.c 2000/07/30 21:05:22 1.155
+++ clock.c 2000/09/04 16:34:16
@@ -194,7 +194,7 @@
static struct timecounter i8254_timecounter = {
i8254_get_timecount,/* get_timecount */
0, /* no poll_pps */
- ~0u,/* counter_mask */
+ 0x1,/* counter_mask */
0, /* frequency */
"i8254" /* name */
};
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | 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: looking for microuptime went backwards victims...
Uhm, that is from the sound driver, not from the timecounter...
Poul-Henning
In message [EMAIL PROTECTED], Josef Karthauser writes:
I got this last night running 'mtv' on a system with heavy disk I/O.
The errors were:
Sep 5 23:12:14 genius /kernel: pcm0: hwptr went backwards 8208 - 8192
Sep 5 23:12:47 genius /kernel: pcm0: hwptr went backwards 8420 - 8192
Sep 5 23:12:57 genius /kernel: pcm0: hwptr went backwards 8212 - 8192
Sep 5 23:13:04 genius /kernel: pcm0: hwptr went backwards 8196 - 8192
Sep 5 23:13:21 genius /kernel: pcm0: hwptr went backwards 8208 - 8192
etc.
Joe
FreeBSD genius.systems.pavilion.net 5.0-CURRENT FreeBSD 5.0-CURRENT #11: Tue Sep 5
12:45:45 BST 2000 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENIUS
i386
On Mon, Sep 04, 2000 at 06:41:14PM +0200, Poul-Henning Kamp wrote:
I'm looking for the remaining victims of the dreaded "microuptime
went backwards" message.
If you can reliably reproduce the problem, please contact me, so
we can arrange for some very detailed tracing to try to find out
what exactly is going on. I have not been able to trigger the
problem in my lab in a long time.
If you see the message only occationally, please try the attached
patch and let me know if this changes the picture. The patch is
not meant as a fix, but it might reduce the impact of this condition
considerably when it happens. Basically by reducing the width of
the timecounter the magnitude of the hit we take if the timecounter
goes backwards is reduced from about an hour to approx 110msec.
Reducing the width to less than 17 bits starts to run the risk of
ambiguity due to clock rollover.
This patch may not be safe with PCAUDIO.
Poul-Henning
Index: clock.c
===
RCS file: /home/ncvs/src/sys/i386/isa/clock.c,v
retrieving revision 1.155
diff -u -r1.155 clock.c
--- clock.c 2000/07/30 21:05:22 1.155
+++ clock.c 2000/09/04 16:34:16
@@ -194,7 +194,7 @@
static struct timecounter i8254_timecounter = {
i8254_get_timecount,/* get_timecount */
0, /* no poll_pps */
-~0u,/* counter_mask */
+0x1,/* counter_mask */
0, /* frequency */
"i8254" /* name */
};
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | 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
--
Josef Karthauser FreeBSD: How many times have you booted today?
Technical Manager Viagra for your server (http://www.uk.freebsd.org)
Pavilion Internet plc. [[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]]
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | 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: New ATA tagged queuing patch available
In message [EMAIL PROTECTED], Matthew Jacob writes: Yeah :) Any chance an older IBM drive might be supported ? IBM-DTTA-351010/T56OA73A Well, the DTTA's say they support tagged queuing, but since the newer DJNA has firmware problems the DTTA probably has that too. To be fair I havn't tried it yet, so if you feel adventurous you can try to add it to the ad_tagsupported function in ata-disk.c and see what happens Gee. You can upgrade F/W in SCSI drives. How about ATA drives? Same thing, the trick is to get the update microcode out of IBM. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | 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: Regarding kldunload / open /dev/dev panic
In message [EMAIL PROTECTED], awr writ es: Also, shouldn't /usr/src/sys/dev/vn/vn.c use make_dev() and destroy_dev() calls instead of cdevsw_add()?? Yes :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | 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: Fdescfs updates--coming to a devfs near you!
In message [EMAIL PROTECTED], Peter Pentchev writes
:
On Thu, Sep 14, 2000 at 01:12:10AM -0700, Julian Elischer wrote:
I've never thought of a use for fdescfs...
Well.. just a trivial example - imagine a program which takes a filename
as an argument; imagine yourself trying to pipe something into it -
passing /dev/fd/0 as a filename to process would do the trick.
I must admit that I think in general that /dev/std{in,out,err} and /dev/fd
is bogus. It looks like something which happened "because we can" more
than something which has a legitimate need.
If anything I would propose we ditch it...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | 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: Fdescfs updates--coming to a devfs near you!
In message [EMAIL PROTECTED], Ben Smithurs
t writes:
Poul-Henning Kamp wrote:
I must admit that I think in general that /dev/std{in,out,err} and /dev/fd
is bogus. It looks like something which happened "because we can" more
than something which has a legitimate need.
You think adding a hack to every program to support "-" to mean
stdout/stdin is better?
The majority of these programs could be handled by adding knowledge
of "-" as a magic filename to fopen(3).
At the same time I would really love if we implemented "|.*" to mean
"do an popen(3)" instead.
But of course, this is bikeshed material...
If anything I would propose we ditch it...
And break loads of scripts at the same time?
I would argue that the programs and the scripts that call them are
already broken, but hey...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | 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: what the heck is ftime and why is the reference undefined???????
In message 003101c01e60$eb3b4e40$[EMAIL PROTECTED], "Ray Seals" wri tes: I need to read the temps off of a 1-Wire Lan. I know about the mlan stuff in the ports, but the themod is set to read an ibutton 1920 device. I'm using a DS1820. I'm not a programmer so I would have the first clue where to even try modifying this for my device. Is anyone using the DS1820 on a 1-Wire Lan with FreeBSD? http://firtal.freebsd.dk/weather/ -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | 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
