new kernel book this summer???
Hi all, I had planned to buy 'Design and Implementation of the BSD 4.4 Operating System' but I heard the rumor that there will be a revision out this summer that will not only be updated, but will focus on FreeBSD. I don't want to repeat any more of the rumor if it is untrue, but I was told if anyone knew the truth, it would be someone on hackers-. :) So, should I wait until summer? Please CC me, I'm not on the list. But I might be after reading the book. ;) jm -- --- Jonathon McKitrick -- [EMAIL PROTECTED] "It took the computing power of three C-64s to fly to the Moon. It takes a 486 to run Windows 95. Something is wrong here." --- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: new rc.diskless{1,2} files
In message [EMAIL PROTECTED]you write:
}
}:
}: On Mar 30, Falco Krepel wrote:
}: I have implemented good ideas from Mike Smith in my
}: rc.diskless{1,2} files and make some other changes:
[...]
}P.S. To anyone who wants to cleanup the rc.diskless files,
}please be my guest! I wrote them originally and they worked
}'ok', but then some people mangled them and ever since they
}haven't worked right. I don't have time to clean them up
}myself. They could use a complete rewriting, IMHO.
}
it would be too presumptios of me to try and clean up, specialy since im
runing -stable, but since im planing on running many 'dataless' workstations
i've been fiddling around with several ideas.
1- i want more than one root-file server.
2- i want the management of the ws to be as centralized as possible
3- not all ws are the same.
so, im willing to spend time/resources.
i've modified (slightly) libstand/bootp.c but haven't received any feedback,
(maybe because there isn't any documentation? :-)
btw, whatever happend to the big rc change (ala sys5/linux)?
danny
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: status of KSE?
On Fri, Mar 16, 2001, David Xu wrote: I know KSE is not related to SMP and will run on UP. my primary idea is want to run parellel I/O task in same process with pthread, simply because FreeBSD pthread does not allow me to do multipile I/O tasks at same time on disk file, of course, it is also conflicted with SYSV IPC, so I think of KSE. I don't care about SMP, CPU is enough fast now, I have already seen 1.3G hz CPU, how fast! I think Intel and AMD can very easy to double their CPU clock, hope I can see 3Ghz CPU in next year. I really do think KSE should work before SMP, but it is obvious not. think about Apache 2.0, it is already multi-threaded, FreeBSD pthread will be blocked at disk I/O, it is very bad for Apache 2.0 . One could theoretically hack the pthreads port into using either external processes for disk IO, or the aio_ routines. Both of these would suffice. (Note that aio_ only does read/write/lseek, whilst open() and close() are still sync, and open() can take quite a while..) Adrian -- Adrian Chadd"Programming is like sex: [EMAIL PROTECTED] One mistake and you have to support for a lifetime." -- rec.humor.funny To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ipfw divert question
Alwyn Goodloe wrote: Hackers, Here's my question. I have the following FW rules: ipfw add 5 divert natd tcp from any to any via ep1 ipfw add 6 divert 4422 tcp from any to any 3322 in ipfw add 65000 allow ip from any to any The first rule is for natd which performs the standard sort of network address translations. THe second is doing some application specific processing. It seems to me that what's happening is that the first divert gets executed and the translation is correct. What I then need is for the second rule to fire on the translated packet. From several things I have read it seems that once one divert rule is executed then the other dirvert rules won't get executed. Am I correct about this. no natd should re-inject the (changed) packets just after the rule that originally diverted them. Any ideas how I can get both divert rules to fire. Alwyn Goodloe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000-2001 --- X_.---._/ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
(sans sujet)
To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Programming the WinBond W83781D
Hi I'm porting a Linux module that reads system health information (such as voltages and temperatures) from a WinBond W83781D chip. What's the best way of extracting such info from the chip? In the Linux module it uses the regular inb(), outb(), set() etc. to read the raw data, and then making it look nice and dandy using a readable file in the proc filesystem. I'm not sure how to do this in FreeBSD.. And what's the best way for a userland program to retrieve the info? I had in mind to just create a kernel module w/direct access to the chip, and make a userland program make the raw data pretty. Thanks for any advice (Even if it's "RTFS!"), Torbjorn Kristoffersen [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: new rc.diskless{1,2} files
}P.S. To anyone who wants to cleanup the rc.diskless files,
}please be my guest! I wrote them originally and they worked
}'ok', but then some people mangled them and ever since they
}haven't worked right. I don't have time to clean them up
}myself. They could use a complete rewriting, IMHO.
I might be one of the guilty ones :) but i have to say, they
seem to work fine on 3.1, 3.3 and even when i tried them on 4.2
they had no problem (except some glitches with mount_null
which at least in 3.1 did not handle too well mmap calls
as used by "cp").
In order to create a shared readonly root partition I use a
script which is available at
http://www.iet.unipi.it/~luigi/clone_root.010401
and basically nothing else. The modified copies of files which
have to replace the original ones in the root partition
are taken from /conf/${IP} or /conf/${SUBNET} or /conf, where
$IP and $SUBNET are the IP address and the local broadcast address
of the first configured network interface. The code in /etc/rc.diskless1
tries to find the longest match from the above.
This lets you centralize the configurations, and yet have
separate configuration files.
It helps a lot to have not just variable assignments in /etc/rc.conf
(typically a "case" statement to do per-machine settings.)
Other than that -- I'd be happy to review (and use!) your changes.
cheers
luigi
it would be too presumptios of me to try and clean up, specialy since im
runing -stable, but since im planing on running many 'dataless' workstations
i've been fiddling around with several ideas.
1- i want more than one root-file server.
2- i want the management of the ws to be as centralized as possible
3- not all ws are the same.
so, im willing to spend time/resources.
i've modified (slightly) libstand/bootp.c but haven't received any feedback,
(maybe because there isn't any documentation? :-)
btw, whatever happend to the big rc change (ala sys5/linux)?
danny
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
Diskless station!!!
Hi. May be some of you can advice me where I can get nb3c509.com file for my diskless station with 3Com509 Ethernet, beceuse I can't run make in netboot directory. Thank you very much for any help. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Security problems with access(2)?
On Sun, Apr 01, 2001 at 10:55:23AM +1000, Greg Black wrote: Many years ago I implemented a new interface that I called eaccess() which replicated the work of access, but tested against the effective uid and gid. I'd like to see that introduced more widely. That still isn't suffient (and even more scary) unless the parameter is a file handle or FILE pointer. We need an faccess() call, plain and simple. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Security problems with access(2)?
On Sun, 1 Apr 2001, David O'Brien wrote: On Sun, Apr 01, 2001 at 10:55:23AM +1000, Greg Black wrote: Many years ago I implemented a new interface that I called eaccess() which replicated the work of access, but tested against the effective uid and gid. I'd like to see that introduced more widely. That still isn't suffient (and even more scary) unless the parameter is a file handle or FILE pointer. We need an faccess() call, plain and simple. As we've discussed off-line, it sounds like what we probably need here are the following: eaccess_file(2) - Using effective credentials, check to see if the requested access is permitted on the file or directory identified by the provided pathname. eaccess_fd(2) - Using effective credentials, check to see if the requested access is permitted on the file or directory associated with the provided open file descriptor. faccess(3) - Using effective credentials, check to see if the requested access is permitted on the file or directory associated with the provided open file stream. Note: the credentials used for eaccess_fd() and faccess() would *not* use the cached credentials associated with the open file descriptor, instead, the effective credentials of the process, meaning that the result would be with respects to the next fd-independent operation performed by the process (unlink(), rename(), open(), ...). Note that, as I described to you previously (and for the benefit of those not privvy to our conversation), it is not sufficient to provide open() as a means to evaluate credentials and an access request for an object, as open() cannot be used on all file system objects. In particular, open() cannot be used on directories in NFS. I've had local implementations of eaccess_file() and eaccess_fd() for a while, as I've used them in GUI-related work so as not to use access(), and not to manually evaluate credentials in userland. Mapping faccess() into eaccess_fd() should be relatively straight-forward, modulo the usual thread-safety in libc. Are we barking up the wrong tree here, or is this in-line with the requirements, and something we should consider implementing and working with to determine whether it meets the needs of various potential consumers? Needless to say, these would be carefully documented, much in the style of access(2), to indicate that these are only appropriate for use in a set of circumstances where the caller is performing a race-free activity. For example, displaying the result to the user in the form of an icon selection, or using access(2) to provide clean failure in a multi-step activity, where the actual access control is performed by the kernel in open(), but the application wants to provide early failure notification so as to fail more cleanly. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 5.0 to have pthreads?
On Sun, Apr 01, 2001 at 11:09:15PM -0400, Arthur Munn wrote: hello all, I was told by a friend that FreeBSD 5.0 is going to be sporting *real* pthreads, I was immediatley very excited and I want to know if this is true, if anyone knows I would really like to have it verified/dismissed. first of all, you have to define 'real pthreads'. freebsd has a perfectly good implimentation of pthreads right now, it just happens to be implimented in userspace. there is also a port of linuxthreads which uses rfork underneath, so gets you process based threads, which gives you many of the advantages of kernel threads, but is rather heavyweight. there is also the KSE project, which is probably what you're talking about. it's intent is to impliment kernel threads in a much more efficient and scalable manner than the rfork based style. check out http://www.freebsd.org/~jasone/kse for details. this project was originally intended for FreeBSD 5.0, but will likely not be completed in time. at the moment i believe it is waiting on the current proc locking work to be completed before any code will be checked in. -- garrett rooney Unix was not designed to stop you from [EMAIL PROTECTED] doing stupid things, because that would http://electricjellyfish.net/ stop you from doing clever things. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Job.
Hi, My company has several job openings -- we really need unix hackers, kernel hackers, real C programmers... We are in Toronto, Canada. If anyone is interested, please tell me what your skills are, and I will refer you guys to the right person. rayson --- Paul Halliday [EMAIL PROTECTED] wrote: hi. Hate to post this here but I need a job... like pronto, today, chop chop. Unfortunately I have zero connections and zero friends (actually two, so they claim but they can't help) so... please listen to my dilema. I have worked in the construction industry for about 6 years working as a commercial/industrial electrician and carpenter. I have finished a maximum of three years of a CIS degree which as far as I was concerened was a total waste of time, and money for that matter. And now have very little to show for it. Anyway, work unfortunately dropped to a lame all time low... Going back to school is not an option and I believe that getting a job in this industry is my only hope to satisfy my soon to be wife. Not to mention supporting our notion of beginning a family. Bottom line, I have a huge fucken debt to pay and have a wedding date already planned for the 18th of August. Long and pathetic story short, I need coin in a big way and fast. IE ( for those that weren't completely listening ) A JOB! I live in Toronto, Ontario and I am willing to pursue any type of work that would be beneficial to any operative on this list that runs some sort of commercial enterprise. I know, FBSD, FBSD, FBSD, FBSD, FBSD, FBSD-ALPHA, FBSD, solaris, linux, obsd, hpux, firewalls, C, BASH ( -elite expressionist shit) and BASH maybe a little ascend, cisco, etc. And probably PDA programming. You name It I will do it. An if not learn it very quickly. If anyone can PLEASE offer something aside from dice, monster, etc, I would prolly lub j00 foreva. Most Humbly ;P -- Paul Halliday Don't underestimate the power of stupid people in large groups. Web: http://www3.sympatico.ca/transmogrify Public Key available here: http://www3.sympatico.ca/transmogrify/dp.txt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/?.refer=text To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Job.
On Sun, Apr 01, 2001 at 08:18:03PM -0700, Rayson Ho wrote: Hi, My company has several job openings -- we really need unix hackers, kernel hackers, real C programmers... We are in Toronto, Canada. If anyone is interested, please tell me what your skills are, and I will refer you guys to the right person. there is a freebsd-jobs mailing list, where this kind of discussion should be conducted. -- garrett rooney Unix was not designed to stop you from [EMAIL PROTECTED] doing stupid things, because that would http://electricjellyfish.net/ stop you from doing clever things. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
5.0 to have pthreads?
hello all, I was told by a friend that FreeBSD 5.0 is going to be sporting *real* pthreads, I was immediatley very excited and I want to know if this is true, if anyone knows I would really like to have it verified/dismissed. thanks! _ Get your FREE download of MSN Explorer at http://explorer.msn.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Routing latency
Devin Butterfield wrote: On Monday 19 March 2001 4:36, Will Andrews wrote: On Mon, Mar 19, 2001 at 07:46:53PM -0500, Dennis wrote: I never got an answer (as usual) from bill paul when I made the suggestions, and noone seemed interested in getting it fixed. He seems to get insulted when I infer that he did something wrong. It's like they say: "money talks". Similarly, "patches talk". Suggestions don't really do that. I'm not defending Dennis here, but this statement infers that nothing gets done unless maintainers are a) paid or b) someone else does the work for them. I certainly hope this is not the case. It is not the case, but it is the case when you want it done RIGHT NOW. You're not allowed to make DEMANDS of a volunteer, as Dennis has done a number of times in the past. There is a lot of history sweeping around this discussion -- feel free to search the archives if you are interested. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Security problems with access(2)?
Robert Watson wrote: | On Sun, 1 Apr 2001, David O'Brien wrote: | | On Sun, Apr 01, 2001 at 10:55:23AM +1000, Greg Black wrote: | Many years ago I implemented a new interface that I called | eaccess() which replicated the work of access, but tested | against the effective uid and gid. I'd like to see that | introduced more widely. | | That still isn't suffient (and even more scary) unless the parameter is | a file handle or FILE pointer. We need an faccess() call, plain and | simple. | | As we've discussed off-line, it sounds like what we probably need here are | the following: | | eaccess_file(2) - Using effective credentials, check to see if the | requested access is permitted on the file or directory identified by the | provided pathname. | | eaccess_fd(2) - Using effective credentials, check to see if the | requested access is permitted on the file or directory associated with | the provided open file descriptor. | | faccess(3) - Using effective credentials, check to see if the requested | access is permitted on the file or directory associated with the | provided open file stream. | | Note: the credentials used for eaccess_fd() and faccess() would *not* use | the cached credentials associated with the open file descriptor, instead, | the effective credentials of the process, meaning that the result would be | with respects to the next fd-independent operation performed by the | process (unlink(), rename(), open(), ...). Note that, as I described to | you previously (and for the benefit of those not privvy to our | conversation), it is not sufficient to provide open() as a means to | evaluate credentials and an access request for an object, as open() cannot | be used on all file system objects. In particular, open() cannot be used | on directories in NFS. | | I've had local implementations of eaccess_file() and eaccess_fd() for a | while, as I've used them in GUI-related work so as not to use access(), | and not to manually evaluate credentials in userland. Mapping faccess() | into eaccess_fd() should be relatively straight-forward, modulo the usual | thread-safety in libc. | | Are we barking up the wrong tree here, or is this in-line with the | requirements, and something we should consider implementing and working | with to determine whether it meets the needs of various potential | consumers? Needless to say, these would be carefully documented, much in | the style of access(2), to indicate that these are only appropriate for | use in a set of circumstances where the caller is performing a race-free | activity. For example, displaying the result to the user in the form of | an icon selection, or using access(2) to provide clean failure in a | multi-step activity, where the actual access control is performed by the | kernel in open(), but the application wants to provide early failure | notification so as to fail more cleanly. I like the way you have proposed this and I think it's a good scheme. I do think it might be a good thing to try to get some support from other camps in the interests of wider portability. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Programming the WinBond W83781D
Torbjorn Kristoffersen writes: I'm porting a Linux module that reads system health information (such as voltages and temperatures) from a WinBond W83781D chip. What's the best way of extracting such info from the chip? In the Linux module it uses the regular inb(), outb(), set() etc. to read the raw data, and then making it look nice and dandy using a readable file in the proc filesystem. I'm not sure how to do this in FreeBSD.. Check out the "healthd" port which shows how to do it via /dev/io or /dev/smb0. -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
