Re: Bursting at the seams (was: Heh heh, humorous lockup)
yeah I remembered how it all worked after I wrote that.. You'd think they'd eventually get the idea of letting the kernel have it's own 'cr3' and some TLBs eh? listenning intel? On 8 Jul 1999, Ville-Pertti Keinonen wrote: [EMAIL PROTECTED] (Julian Elischer) writes: we already use the gs register for SMP now.. what about the fs register? I vaguely remember that the different segments could be used to achieve this (%fs points to user space or something) You can't extend the address space that way, segments are all parts of the single 4GB address space described by the page mapping. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Bursting at the seams (was: Heh heh, humorous lockup)
[EMAIL PROTECTED] (Julian Elischer) writes: we already use the gs register for SMP now.. what about the fs register? I vaguely remember that the different segments could be used to achieve this (%fs points to user space or something) You can't extend the address space that way, segments are all parts of the single 4GB address space described by the page mapping. True, but you can reserve a part of the 4GB address space (say 128MB of it) for partitioning into tiny (say 8MB) address spaces (which are still flat, just small), for use by small processes, the idea being that all those small processes will than share a single page table without compromising on memory protection (the GDT is under full OS's control anyway), or the simplicity of a flat address space (virtual addresses still start at 0 and continue till the top of address space; the scheme is totally transparent.) patryk. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Bursting at the seams (was: Heh heh, humorous lockup)
[EMAIL PROTECTED] (Patryk Zadarnowski) writes: You can't extend the address space that way, segments are all parts of the single 4GB address space described by the page mapping. True, but you can reserve a part of the 4GB address space (say 128MB of it) for partitioning into tiny (say 8MB) address spaces (which are still flat, just small), for use by small processes, the idea being that all those small processes will than share a single page table without compromising on memory protection (the GDT is under full OS's control anyway), or the simplicity of a flat address space (virtual addresses still start at 0 and continue till the top of address space; the scheme is totally transparent.) Yeah, I know, I've read Liedtke's original paper where he described the optimization in L3, that's fine for that specific purpose, but that wasn't what the thread was about. Unless I totally missed the point. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Replacement for grep(1) (part 2)
On Wed, 7 Jul 1999, Jamie Howard wrote: The FreeBSD, NetBSD, and OpenBSD manpage for grep says this: Grep understands two different versions of regular expression syntax: ``basic'' and ``extended.'' In GNU grep, there is no difference in available functionality using either syntax. Is this inaccurate or am I reading it wrong? I think that you are reading it wrong. It means "If you have a task that can be performed in GNU grep using a regexp in one syntax, then the same task can also be performed in GNU grep using a regexp in the other syntax". It does not also mean "... and the regexps in the two syntaxes will be identical". For example, if your task is "find lines that contain the characters open-parenthesesXclose-parentheses" then you can use the basic RE '(X)' or the extended RE '\(X\)'. You can get the same functionality using either syntax, but the way you get that functionality will depend on which syntax you are using. --apb (Alan Barrett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: docs/12377: doc patch for login_cap.
On Thu, 08 Jul 1999 00:03:10 +0100, Nik Clayton wrote: I have done. As far as I can tell, the submitter is saying "Yes, the information I was looking for was in the manual page, but it (specifically, that the "root" account doesn't use the "default" entry) is buried as a throw away comment at the end of a long paragraph." No. The PR suggests a fix to a completely different paragraph, describing a different function. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
need a better solution as callback
hi to all, i have a freebsd installed with internet connection on my desktop pc and on my laptop as well. because i am traveling a lot between two countries, i'd like to make followings. - laptop dials to my desktop pc - laptop sends some command - desktop hangs up and dials to local isp - laptop dials also to a local isp - desktop sends a mail to me that means it is online (sends an ip address as well) - laptop logs in is it too much? any idea? thx geza _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: need a better solution as callback
Geza Fodor wrote: i have a freebsd installed with internet connection on my desktop pc and on my laptop as well. because i am traveling a lot between two countries, i'd like to make followings. You should be able to write some scripts which do this; theoretically, the "some commands to my desktop pc" bit can be an invocation of a background script which time-delays then initiates a PPP connection. - mark - laptop dials to my desktop pc - laptop sends some command - desktop hangs up and dials to local isp - laptop dials also to a local isp - desktop sends a mail to me that means it is online (sends an ip address as well) - laptop logs in is it too much? any idea? Mark Newton Email: [EMAIL PROTECTED] (W) Network Engineer Email: [EMAIL PROTECTED] (H) Internode Systems Pty Ltd Desk: +61-8-82232999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now worksunder New Midi Driver Framework with a Fine Timer)
On Thu, 8 Jul 1999 09:54:42 +0100 (BST), Doug Rabson [EMAIL PROTECTED] said: dfr If I understand this correctly, you are suggesting that we program timer0 dfr so that we only take interrupts when a finetimer is due to fire? If so, dfr then it sounds very good. The idea of taking 6000+ interrupts/sec made me dfr uneasy, even though most would return without doing any work. Yes, that is what I am doing now. And some further discussion... t' \sum_(k=0)^(j) dt_rem(c_k) where the right hand side of the inequality is the time span after which the callout c_k is made. Then c' is inserted after c_j and new dt_rem(c_(j+1)) and dt_rem(c_(j+2)) are determined. Now we can acquire_timer0() with dt_rem(c_0). If t' is less than dt_rem(c_0) then we have no feasible j. This is the case in which we must reaquire_timer0() using t'. Then, after interting c', dt_rem(c_1) is updated to be (dt_rem(c_1) - (time elapsed since the last aquire_timer0())), so that c_1 can be armed later. There is one problem in this method. acquire_timer0() is only implemented for i386. We would need to write something equivalent for alpha... Seigo Tanimura [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Clipboard Daemon - thinking of writing one :)
On Thu, 8 Jul 1999, Mikhail Ramendik wrote: Hello! I am new to FreeBSD and Unix, but not new to programming and TCP/IP. I have noticed that there is no good clipboard system in FreeBSD. X has only a rudimentary clipboard, and outside X there is no clipboard that would be shared between programs... All this while Windows has a very interesting clipboard system that allows to paste as different types. Retrofitting this kind of thing will almost certainly be hard: Microsoft has the advantage of writing the toolkits used by their application developers, and getting to change the rules at any point in time. Similarly, Microsoft hasn't delivered the network services that you describe below, either. :) Microsoft also has the advantage of being able to liberally mix the operating system and application space. In UNIX-land, the entire windowing system and toolkits on top are replaceable, meaning that there is more flexibility, but fewer standards other than de-facto standards. Consider instead placing your work in the context of an object system (see below) such as GNOME or KDE. I am thinking of writing a Clipboard Demon (of course, free and documented and source and all) to try and tackle this problem. It's going to be a daemon working over IP, it will allow "named clipboards" so that by default each user has one clipboard, but a user can start several clipboards and/or share one over a network (ok, insecure, at least in first releases - but then, it can be nonsensitive info over a LAN). It will allow a program to export data into the clipboard in one or _several_ formats (MIME, of course), and then it will allow the importing program to choose the format it wants (a la Windows, but no OLE stuff here) and get the data in it. Security will be an issue here. The traditional way to do this kind of thing is in the context of an existing distributed system of some kind, relying in its services for connection management, data format management, etc. A few considerations you might want to examine would be single-host security (who owns what data, when can different things be copied, pasted -- xterm runs as root, your shell runs as you, your X server runs as root, etc, etc), multi-host security (cryptography, mapping users between systems, existing distributed authentication schemes (kerberos, for example), etc), and access control -- will you have shared clipboards? For example, a GUI text editor can export the text as native format, text, formatted text (RTF?), vector graphics (unsure what format would replace WMF here), bitmap. This same editor will paste the native by default, another editor will use the formatted text by default, etc. Note that it will work independently of X. So I can copy in Joe then paste to GIMP (as text), if both support the clipboard. I will probably have time for actual coding in August or September. But I want to work out the specs first, and to make sure it's needed at all ;) So, my questions are: - Whether this thing is, in your opinion, needed It sounds extremely useful. Network support is something that would be very nice to have, although you may be replicating work in distributed file systems. It might be worthwhile to consider whether an existing distributed file system might be a better time investment (Coda, AFS/Arla, etc) because it would provide a decent transport with a namespace, authentication, ACLs, etc. - Whether a similar solution already exists in the freenix world (perhaps in Linux?) Might want to look into the various distributed object models being considered (don't both the KDE and GNOME people have some interest in this?). I don't know much about them (KDE uses CORBA maybe?), but the chances are they have at least begun to address some of the complicated issues that you would need to look at. - How to handle "big" data? If a program exports a big graphic in several formats, that's a lot of data... Well, it can not actually send the data but only indicate it's available - but then we'd have to "call back" to receive the data, so the program would need to have a permanent connection with the daemon and "listen" to it, and the availability of data would cease when the program quits. Should I nevertheless include this behaviour as an option, to be decided by the exporting program? Now the newbie questions: - Where can I read a good text on writing FreeBSD daemons? - How can I choose a guaranteed free TCP port? www.iana.org IANA -- Internat Assigned Numbers Authority Yours in Christ, Mikhail Ramendik Moscow, Russia Your project sounds interesting, but I suspect that you may want to reconsider your approach. It might make more sense to have a distributed database or network accessible database capable of managing typed data, access control, authentication, etc, and then a local daemon that communicates with it, as well as to library hooks in applications via file system socket capable of
Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now worksunderNew Midi Driver Framework with a Fine Timer)
On Thu, 8 Jul 1999, Seigo Tanimura wrote: On Thu, 8 Jul 1999 09:54:42 +0100 (BST), Doug Rabson [EMAIL PROTECTED] said: dfr If I understand this correctly, you are suggesting that we program timer0 dfr so that we only take interrupts when a finetimer is due to fire? If so, dfr then it sounds very good. The idea of taking 6000+ interrupts/sec made me dfr uneasy, even though most would return without doing any work. Yes, that is what I am doing now. And some further discussion... t' \sum_(k=0)^(j) dt_rem(c_k) where the right hand side of the inequality is the time span after which the callout c_k is made. Then c' is inserted after c_j and new dt_rem(c_(j+1)) and dt_rem(c_(j+2)) are determined. Now we can acquire_timer0() with dt_rem(c_0). If t' is less than dt_rem(c_0) then we have no feasible j. This is the case in which we must reaquire_timer0() using t'. Then, after interting c', dt_rem(c_1) is updated to be (dt_rem(c_1) - (time elapsed since the last aquire_timer0())), so that c_1 can be armed later. There is one problem in this method. acquire_timer0() is only implemented for i386. We would need to write something equivalent for alpha... The timer hardware on the alpha is essentially the same but the interrupts are wired up differently. I'm not sure how hard it would be to get timer0 working but I think it should be possible. The alphas tend to run the main clock quite fast (typically 1024hz) so the granularity of timing is better but probably not good enough for midi or pca. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now worksunderNew Midi Driver Framework with a Fine Timer)
On Thu, 8 Jul 1999 11:00:24 +0100 (BST), Doug Rabson [EMAIL PROTECTED] said: There is one problem in this method. acquire_timer0() is only implemented for i386. We would need to write something equivalent for alpha... dfr The timer hardware on the alpha is essentially the same but the interrupts dfr are wired up differently. I'm not sure how hard it would be to get timer0 dfr working but I think it should be possible. I see. Then I can work on i386 first, and later on alpha. dfr The alphas tend to run the main clock quite fast (typically 1024hz) so the dfr granularity of timing is better but probably not good enough for midi or dfr pca. I agree. Seigo Tanimura [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Clipboard Daemon - thinking of writing one :)
On Thu, 8 Jul 1999, Mikhail Ramendik wrote: I have noticed that there is no good clipboard system in FreeBSD. X has only a rudimentary clipboard, and outside X there is no clipboard that would be shared between programs... All this while Windows has a very interesting clipboard system that allows to paste as different types. This is why Private Name Spaces are a good thing. They act like a file system (because they are a file system), they can be backed by a file system or whatever you wish (i've got both memory servers and file system servers) and they allow processes to create shared, private data to support such things as a clipboard. You don't need to write a special daemon, you just need to get private name spaces working on freebsd. I have a first piece in the v9fs file system, which is a memory file system but which is intended to support private name spaces in the future. Note that private name spaces work just fine over a network. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Bursting at the seams (was: Heh heh, humorous lockup)
:yeah I remembered how it all worked after I wrote that.. :You'd think they'd eventually get the idea of letting the kernel have it's :own 'cr3' and some TLBs eh? : :listenning intel? This is intel we are talking about. Their mmu/cache technology is always a few years behind the times. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: implementing a fs on a raw partition
If someone in the FS dept. would draw up a broad outline for FS implementation I hereby volunteer to flesh it out thoroughly and donate the end-product docs to the FreeBSD project. I am a professional UNIX (AIX/SOLARIS) programmer and fairly clueful kernel source peruser and tweaker, fully capable of producing professional quality technical documentation. I propose the following iterative process: 1) FS guru draws up broad scheme. 2) I flesh it out with resort to trial and error research, trying very hard to figure everything out for myself but ask precisely worded usually Y/N questions when I get good and stumped. 3) I submit draft for inspection by FS people, receive feedback. 4) I repair draft goto (2) Please refer only to 3.x 4.x methodology in the broad scheme. We'll make this a baseline and allow any deprecated stuff to properly atrophy into mummy dust. The purpose of this exercise is to produce a definitive procedure for coding new filesystems for use in the FreeBSD kernel. Benefits include speed of porting of 'foreign' FSes and feedback to the core group on implementation issues. Please CC [EMAIL PROTECTED] and [EMAIL PROTECTED] in replies. The wife is 10 days overdue to deliver a baby and I'll (God, hopefully) be on vacation all next week and in sleep deprivation hallucinatory mode. -Original Message- From: Marc Tardif [SMTP:[EMAIL PROTECTED]] Sent: Wednesday, July 07, 1999 9:22 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: implementing a fs on a raw partition As I reading on filesystem algorithms and principles [bach 86 and mckusick 96], I am tempted to try my hand on a free partition. From my understanding, I should be using the partition as a character device for raw i/o in order to avoid the current filesystem overhead (/dev/rwd0s3). From that point, I've been using the code from /usr/src/sys/msdosfs in order to get something going at first... but this has shown to be an exhausting task. I keep running into dependencies and such which make it seem impossible to implement. Perhaps I have taken a wrong turn at Albuquerque, so I'd appreciate if anyone could give a hint to get me up and running. Thanks in advance, Marc [bach 86] The Design of the UNIX Operating System, Maurice J. Bach [mckusick 96] The Design and Implementation of the 4.4BSD Operating System, Marshall McKusick, Keith Bostic, Michael J. Karels, John S. Quarterman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-fs" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
mbuf shortages
If a system runs out of mbufs can memory be claimed from elsewhere or is the system pretty much dead especially for networking related allocations. jayanth To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Problem with fxp driver and 82559 cards
However, we have at least one industrial-type system (with a different board/config) that works fine with these cards, though we didn't do the install with one. I'll try that tomorrow and report my findings. Though the cards seem to work post-install, they fail in the install program. I can transfer files to my hearts content using the ftp program... but if I go into the installer and try to transfer a distribution , it fails, locking in the same way. I'm talking with Intel to see if they have had similar problems. I read something in the source about the reciever has locked after garbage in the syncronization bits... could it be a similar problem with the new chip, perhaps exposed by certain types of equipment? Any suggestions as to what I should look into? It sounds like a motherboard chipset problem. It's a standard intel chipset... I'm getting a replacement BIOS to see if that makes a difference. Thanks, Jay To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: docs/12377: doc patch for login_cap.
Nope, I did read the docs, hence the patch to the manpage to make it stand out more clearly. I still am of the opinion that "default" should mean "default" for everyone. AFIK, there are no other fields in passwd that have different interpretations/defaults depending upon the UID. This is why I made my remarks about this being a violation of the principle of least surprise. My PR took the very conservative approach of just amplifying the documentation rather than making any funictional changes whatsoever. If a patch that make "default" the true default for all user and then explicitly set root's default class to 'root' would be accepted, I am willing to provide one. IMHO, this would be cleaner. The semantics of multiple default values boggles my mind. cheers, Adrian -- [ [EMAIL PROTECTED] -- Ubergeeks Consulting -- http://www.ubergeeks.com/ ] On Tue, 6 Jul 1999, Sheldon Hearn wrote: On Mon, 05 Jul 1999 23:56:17 +0100, Nik Clayton wrote: I'm unfamiliar with the ins and outs of the login_cap system. Could someone who is versed in it please take a look at this PR (text included) and let me know whether or not the suggested patch is correct. Quite often, we receive requests to improve documentation that are born out of a failure to read that documentation correctly. I think this PR might be one of those cases. Have a look at the login_cap(3) manpage, into which I suspect the submitter may not have dug deeply enough: The functions login_getpwclass(), login_getclass() and login_getuserclass() retrieve the applicable login class record for the user's passwd entry or class name by calling login_getclassbyname(). On failure, NULL is returned. The difference between these functions is that login_getuserclass() includes the user's overriding .login_conf that exists in the user's home directory, login_getpwclass,() and login_getclass() restricts loookup only to the system login class database in /etc/login.conf. login_getpwclass() only differs from login_getclass() in that it allows the default class for user 'root' as "root" if none has been specified in the password database. Otherwise, if the passwd pointer is NULL, or the user record has no login class, then the system "default" entry is retrieved. Regards, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message Adrian -- [ [EMAIL PROTECTED] -- Ubergeeks Consulting -- http://www.ubergeeks.com/ ] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Problem with fxp driver and 82559 cards
However, we have at least one industrial-type system (with a different board/config) that works fine with these cards, though we didn't do the install with one. I'll try that tomorrow and report my findings. Though the cards seem to work post-install, they fail in the install program. I can transfer files to my hearts content using the ftp program... but if I go into the installer and try to transfer a distribution , it fails, locking in the same way. I'm talking with Intel to see if they have had similar problems. I read something in the source about the reciever has locked after garbage in the syncronization bits... could it be a similar problem with the new chip, perhaps exposed by certain types of equipment? What's the cable plugged into? -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Problem with fxp driver and 82559 cards
program... but if I go into the installer and try to transfer a distribution , it fails, locking in the same way. I'm talking with Intel to see if they have had similar problems. I read something in the source about the reciever has locked after garbage in the syncronization bits... could it be a similar problem with the new chip, perhaps exposed by certain types of equipment? What's the cable plugged into? We have tried: ATI switch (centrecom 3124tr) 10bT 3com SuperStack II (10/100) SMC TigerSwitch 10bT Same results on all of them. We've also tried setting media type to 10baseT/UTP in the 'ifconfig options' in sysinstall... no difference. Jay To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now worksunder New Midi Driver Framework with a Fine Timer)
this is problematic. you cannot add a new element before the pending firing because you can't tell how far into the present trigger you are. On Thu, 8 Jul 1999, Doug Rabson wrote: On Thu, 8 Jul 1999, Seigo Tanimura wrote: On Wed, 7 Jul 1999 19:46:38 -0700 (PDT), Julian Elischer [EMAIL PROTECTED] said: julian With your scheme the clock needs to be always running at elevated speed. julian Possibly you might have a startup routine that turns on the elevated julian frequency, (basically does an 'aquire_timer0()' ) I would say that you julian would have more success in implementing your finetimer() by using julian "aquiretimer0" than the other way around. I agree that acquire_timer0() would give more freedom to the ticks to callout. Then I tried figuring out how to manage multiple callouts using acquire_timer0(), which is something like below. Let C the callout queue, and c_i a callout. (0 = i I) Next define f(c_i) as the callout function of c_i, and dt_rem(c_i) the time span between c_(i-1) and c_i. (dt_rem(c_-1) is defined as zero) We use the time span to avoid traversing though the queue to update the time tags on the callouts. (footnote: I'd better write in TeX :-) Queueing a new callout c' to be made in t' involves a problem to find the maximum j (which is an integer, j = 0) satisfying a constraint t' \sum_(k=0)^(j) dt_rem(c_k) where the right hand side of the inequality is the time span after which the callout c_k is made. Then c' is inserted after c_j and new dt_rem(c_(j+1)) and dt_rem(c_(j+2)) are determined. Now we can acquire_timer0() with dt_rem(c_0). In clkintr(), we dequeue c_0 from C, and make a callout to f(c_0). Then acquire_timer0() is called once more with the new dt_rem(c_0). dt_rem(c_i) is the difference of callout times, so they need not be updated on every clkintr(). Although the computational cost in clkintr() is generaly O(1), the queueing cost is O(I). Not sure whether we can reduce it or not (will it really make a trouble?) How does it sound? If I understand this correctly, you are suggesting that we program timer0 so that we only take interrupts when a finetimer is due to fire? If so, then it sounds very good. The idea of taking 6000+ interrupts/sec made me uneasy, even though most would return without doing any work. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd.Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: need a better solution as callback
Hi! I saw your posting on the HU list and was actually able to understand the Subject: line! (I guess it wasn't that difficult) It's fun to se the 'correct translation' so I could compare.. julian On Thu, 8 Jul 1999, Geza Fodor wrote: hi to all, i have a freebsd installed with internet connection on my desktop pc and on my laptop as well. because i am traveling a lot between two countries, i'd like to make followings. - laptop dials to my desktop pc - laptop sends some command - desktop hangs up and dials to local isp - laptop dials also to a local isp - desktop sends a mail to me that means it is online (sends an ip address as well) - laptop logs in is it too much? any idea? thx geza _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com 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
Strange select/poll behaviour [EBADF inconsistancy]
Hi,
The following program returns an inconsistant rc/errno value.
Setting a bit corresponding to filedescriptor which is not open
is only found when it is less than 20. ie:
Some example output follows along with the program. This is being
run on a -current system. If I open a file on fd 1023 then I receive
EBADF all the way through which is what I expect. Our product depends
on this behaviour (no, don't ask)...
The man page specfies:
The first nfds descriptors are
checked in each set; i.e., the descriptors from 0 through nfds-1 in the
descriptor sets are examined.
I've seen that select seems to call poll, but I haven't trace
all the way through poll yet.
Any comments, critiques, or stupid user pointers are appreciated.
Thanks!
John
[3] : Bad file descriptor
[4] : Bad file descriptor
[5] : Bad file descriptor
[6] : Bad file descriptor
[7] : Bad file descriptor
[8] : Bad file descriptor
[9] : Bad file descriptor
[ 10] : Bad file descriptor
[ 11] : Bad file descriptor
[ 12] : Bad file descriptor
[ 13] : Bad file descriptor
[ 14] : Bad file descriptor
[ 15] : Bad file descriptor
[ 16] : Bad file descriptor
[ 17] : Bad file descriptor
[ 18] : Bad file descriptor
[ 19] : Bad file descriptor
[ 20] Timeout
[ 21] Timeout
[ 22] Timeout
[ 23] Timeout
[ 24] Timeout
[ 25] Timeout
#include stdio.h
#include unistd.h
#include errno.h
#include fcntl.h
#include sys/time.h
#include sys/stat.h
static struct timeval nowait_s = {0, 0}; /* poll, no wait */
static struct timeval wait_s = {0, 100}; /* poll, wait 1 sec*/
fd_set local_rfd;
fd_set local_wfd;
main()
{
intn;
struct timeval *tp;
intmax_fd = -1;
intcount;
intbytes;
intwait_time;
int i;
char * p;
char buffer[256];
fprintf(stderr,"FD_SETSIZE = %d\n",FD_SETSIZE);
for(i=3;i40;++i)
close(i);
for(i=3;i40;i++)
{
bzero(local_rfd,sizeof(local_rfd));
bzero(local_wfd,sizeof(local_wfd));
FD_SET(i,local_rfd);
tp = wait_s;
n = select (200,local_rfd, 0, 0, tp);
if (n 0 )
{
sprintf(buffer,"[%5d] ",i);
perror(buffer);
continue;
}
if (n == 0 )
{
printf("[%5d] Timeout\n",i);
}
if (n 0)
{
if ( FD_ISSET(0, local_rfd) )
{
printf("[0] READ\n");
}
if ( FD_ISSET(i, local_rfd) )
{
printf("[%5d] READ\n",i);
}
}
}
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Pictures from USENIX
I'm not asking any of you to prepare a resume - we're starting JUST with the core team bios and pictures here. :) i knew you were not humans... cheers luigi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Strange select/poll behaviour [EBADF inconsistancy]
In article local.mail.freebsd-hackers/[EMAIL PROTECTED] you write: Hi, The following program returns an inconsistant rc/errno value. Setting a bit corresponding to filedescriptor which is not open is only found when it is less than 20. ie: This is because initially, only 20 descriptors are allocated, and the system is quietly ignoring any descriptors over the allocated amount: if (uap-nd p-p_fd-fd_nfiles) uap-nd = p-p_fd-fd_nfiles; /* forgiving; slightly wrong */ This should be: if (uap-nd p-p_fd-fd_nfiles) return (EBADF); -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Strange select/poll behaviour [EBADF inconsistancy]
:This is because initially, only 20 descriptors are allocated, and :the system is quietly ignoring any descriptors over the allocated :amount: : :if (uap-nd p-p_fd-fd_nfiles) :uap-nd = p-p_fd-fd_nfiles; /* forgiving; slightly wrong */ : :This should be: : :if (uap-nd p-p_fd-fd_nfiles) : return (EBADF); : :-- :Jonathan Not unless you want to blow up virtually every program that uses select!!! Passing an nd parameter that is greater then the current number of descriptors is perfectly valid. It's setting a bit in the bitmask for one of those descriptors that should return EBADF! -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Strange select/poll behaviour [EBADF inconsistancy]
On Jul 07, 1999 at 02:33:19PM -0700, Matthew Dillon wrote: Not unless you want to blow up virtually every program that uses select!!! Passing an nd parameter that is greater then the current number of descriptors is perfectly valid. It's setting a bit in the bitmask for one of those descriptors that should return EBADF! Hmm, you're right. Arguably, it could return EINVAL. Actually, the man page documents this behavior, although it gets the 256 number wrong. If nfds is greater than the number of open files, select() is not guaran- teed to examine the unused file descriptors. For historical reasons, select() will always examine the first 256 descriptors. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Strange select/poll behaviour [EBADF inconsistancy]
:Hmm, you're right. Arguably, it could return EINVAL. Actually, the :man page documents this behavior, although it gets the 256 number wrong. : : If nfds is greater than the number of open files, select() is not guaran- : teed to examine the unused file descriptors. For historical reasons, : select() will always examine the first 256 descriptors. : :-- :Jonathan This piece of the manual is justifying the fact that select() is not currently checking past the current number of open files -- which is how select() works now. The second part of that manual entry is just plain wrong: If you pass an nd value less then 256 it will only check that number of descriptors, it no longer examines a minimum of 256. It would definitely not be appropriate to return EINVAL. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
dbm_* manpages for review
-hackers, Tim Singletary has written some man pages for the dbm_* functions in libc, which are currently undocumented -- we know they are written in terms of dbopen(), but it's nice to have them documented anyway. Could anyone who knows anything about DBM take a look at docs/12557 and let me know if they are correct? If they are, I'll commit them. Cheers, N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: support for i386 hardware debug watch points
I just wondered if this should be integrated into ptrace(), so the various debuggers wouldn't have to know about it. It seems that would be the proper abstraction - hardware that supports it would "have it" - and the programs that "used it" wouldn't have to know anything special. I only have a passing knowledge of ptrace() - so, I may be totally wrong... - Dave Rivers - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: need a better solution as callback
hi to all, i have a freebsd installed with internet connection on my desktop pc and on my laptop as well. because i am traveling a lot between two countries, i'd like to make followings. - laptop dials to my desktop pc - laptop sends some command - desktop hangs up and dials to local isp - laptop dials also to a local isp - desktop sends a mail to me that means it is online (sends an ip address as well) - laptop logs in is it too much? any idea? You can do better. Make the mgetty+sendfax port and run vgetty instead of mgetty. Set up your voice stuff (you'll need to copy the vgetty example config manually) and then create a dtmf.sh script. You can then dial your home machine on a handset, type in the correct DTMF sequence and have your machine connect to the 'net - you don't need to have direct dial access from your laptop :-) Ppp happily does this if you just give it a reasonable redial period frequency. thx geza -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.Awfulhak.org [EMAIL PROTECTED] Don't _EVER_ lose your sense of humour ! [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Replacement for grep(1) (part 2)
Dag-Erling Smorgrav wrote:
Assar Westerlund [EMAIL PROTECTED] writes:
Dag-Erling Smorgrav [EMAIL PROTECTED] writes:
+ realpat = grep_malloc(strlen(pattern) + sizeof("^(")
+ + sizeof(")$") + 1);
Why not just use asprintf?
Doesn't matter, thsis code is gone in the latest version. You though
the linux 'kernel of the day' was bad; now you have the FreeBSD 'grep
of the minute' :)
You guys need the infamous two-headed-editor from 'Dave-n-Val the two-
headed programmer' at Weber State. It allows two programmers to edit
the same file on two terminals; it displays the line of code the OTHER
user's cursor is on in red and won't let your cursor on that line.
;^)
--
"Where am I, and what am I doing in this handbasket?"
Wes Peters Softweyr LLC
http://softweyr.com/ [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Wrong comment in VM code?
At the beginning of the file vm_object.c, we have the following comment: The only items within the object structure which are modified after time of creation are: reference count locked by object's lock pager routine locked by object's lock But at the end of vnode_pager_setsize(), we modify the size field. So at least three items can be modified after creation. Am I right? Thanks for any help. -- Zhihui Zhang. Please visit http://www.freebsd.org -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Simplifying Vinum (was: ufs/ffs resize?)
I think you'll find, once you get that far, that things are anything but trivial. I'm certainly open to suggestions, but consider: vinum -i /dev/something volumename Where does it insert it? What if the volume has more than one plex, which it will in the case of a mirror? OK, perhaps I was getting a little carried away here. :) Not if they're done well. I'm open to suggestions. Here are couple of possibilities: add commands "cat", "stripe" and "mirror": vinum cat /dev/da1h /dev/da2h vinum stripe /dev/da1h /dev/da2h /dev/da3h /dev/da4h vinum mirror /dev/da1h /dev/da2h vinum mirror /dev/da1h /dev/da2h /dev/da3h /dev/da4h These sound just fine to me! And what about the names? It seems tacky to have to write down the name that Vinum chooses. How about adding a name parameter, either implicitly or explicitly? For example, vinum cat myvol /dev/da1h /dev/da2h vinum cat -n myvol /dev/da1h /dev/da2h I also think that's a better proposal than mine, yes. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: support for i386 hardware debug watch points
From: Thomas David Rivers [EMAIL PROTECTED] I just wondered if this should be integrated into ptrace(), so the various debuggers wouldn't have to know about it. It seems that would be the proper abstraction - hardware that supports it would "have it" - and the programs that "used it" wouldn't have to know anything special. I only have a passing knowledge of ptrace() - so, I may be totally wrong... - Dave Rivers - I think 'ptrace()' provides a natural interface for doing this. Under the covers, the 'ptrace()' calls are actually mapped to the corresponding procfs filesystem calls. While it is certainly possible to get at the registers using the more direct /proc/$pid/dbregs file, for historical reasons, the 'ptrace()' interface is probably the more expected method, and does not require issuing an open(), read(), write(), close() sequence. I've studied the code for 'gdb', and specifically the Linux support for their hardware debug registers. They use: ptrace (6, pid, offsetof (struct user, u_debugreg[DR_CONTROL]), debug_control_mirror); ptrace (6, pid, offsetof (struct user, u_debugreg[free_debug_register]), addr); Why they've hardcoded a '6' there I can't fathom, but it represents the PT_WRITE_U request to write directly into the child's user structure. Not only does this method require knowledge of x86 debug registers, but it also requires some knowledge of Linux internals. By providing a PT_[GET/SET]DBREGS request to 'ptrace()' in FreeBSD, which not by accident works identically to the existing PT_GET/SETREGS, and PT_GET/SETFPREG for getting/setting the general purpose and floating point processor registers, debuggers can focus on the hardware architecture, without having to be too concerned with obscure offsets of data within system data structures. In this respect, it actually results in less information that the programmer has to be aware of or keep track of. As far as providing a higher layer of abstraction, I must argue that these registers are primarily used only by debuggers, which must possess a very detailed kowledge of the underlying hardware by default. Thus, hiding the debug registers does not offer that much, however, exposing them to the debugger for complete control, can result in the complete debug support that is provided by the target architecture, as opposed to the subset that is supported across multiple architectures, that a higher level of abstraction implies. I suppose that in my view, I don't really see any difference in accessing the debug registers as accessing the general purpose registers or floating point registers, which is the model I used for this implementation. Also, this implementation currenly supports only those features that are available all the way back to the i386. Sorry for being so wordy. I should have provided some explanation for some of the design decisions that I made for this implementation when I posted my patches. I certainly hope that this work will be committed, because I think it adds a nice feature (once gdb supports it), especially for anyone who does non-trivial software development and debugging. Also, I must compliment the FreeBSD kernel folks ... the well designed internals of FreeBSD allowed a very clean implementation of this support. I did not have to do anything tricky to make it work. The framework was essentially there, I just had to "plug in" at the appropriate places in the kernel. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Simplifying Vinum (was: ufs/ffs resize?)
On Thursday, 8 July 1999 at 18:52:41 -0700, Jordan K. Hubbard wrote: I think you'll find, once you get that far, that things are anything but trivial. I'm certainly open to suggestions, but consider: vinum -i /dev/something volumename Where does it insert it? What if the volume has more than one plex, which it will in the case of a mirror? OK, perhaps I was getting a little carried away here. :) Not if they're done well. I'm open to suggestions. Here are couple of possibilities: add commands "cat", "stripe" and "mirror": vinum cat /dev/da1h /dev/da2h vinum stripe /dev/da1h /dev/da2h /dev/da3h /dev/da4h vinum mirror /dev/da1h /dev/da2h vinum mirror /dev/da1h /dev/da2h /dev/da3h /dev/da4h These sound just fine to me! And what about the names? It seems tacky to have to write down the name that Vinum chooses. How about adding a name parameter, either implicitly or explicitly? For example, vinum cat myvol /dev/da1h /dev/da2h vinum cat -n myvol /dev/da1h /dev/da2h I also think that's a better proposal than mine, yes. OK. This goes back to a message I wrote a long time ago. It's been a week since I committed the changes. Here's what we have (from vinum(8)): concat [-f] [-n name] [-v] drives Create a concatenated volume from the specified drives. mirror [-f] [-n name] [-s] [-v] drives Create a mirrored volume from the specified drives. stripe [-f] [-n name] [-v] drives Create a striped volume from the specified drives. The -s flag to mirror states whether to create concatenated or striped plexes for the mirror. Striped plexes always have stripes of 256 kB. For more details, RTFM. Greg -- See complete headers for address, home page and phone numbers finger [EMAIL PROTECTED] for PGP public key To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
matcd on an SB16
I've been following a local Linux mailing list, and a couple of the
users there have been trying FreeBSD ('cos I'm giving a presentation on
it at a Linux user group meeting next month :-)
One of them has an SB16 with a CD-ROM drive. His attempts at installing
FreeBSD from that CD-ROM have met with abysmal failure:
$ Next came an install on my Pentium 60 (previously running Caldera-2.2)
$ - A total disaster no way despite 12 attempts to install, could I
$ get FreeBSD to actually initialise the sbpcd (freebsd calls it matcdc)
$ despite changing IO's, entering the manual configuration option etc
$ etc... it would not could not, find the cdrom so I had to abort the
$ install every time!!
Is the matcd driver known to work on FreeBSD 3.2 ? If not, does anyone
have any estimate of the amount of effort that'd be required to fix it?
- mark
Is the matcd driver known to work on FreeBSD 3.2 ? If not, does anyone
have any estimate of the amount of effort that'd be required to fix it?
- mark
Mark Newton Email: [EMAIL PROTECTED] (W)
Network Engineer Email: [EMAIL PROTECTED] (H)
Internode Systems Pty Ltd Desk: +61-8-82232999
"Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
sigaction inconsistancy (here I go again)
Hi,
Running -current...
I'm trying to verify SIGFPE handling and am finding some
interesting issues. In the following test program, a divide
by zero is done and the SIGFPE delivered.
$ ./fp
sig == 8
code== 0
z has the value 1.00
It seems that from machine/trap.h the value of code should
have been:
/* codes for SIGFPE/ARITHTRAP */
#define FPE_FLTDIV_TRAP 0x3 /* floating/decimal divide by zero */
ie: 3 and not 0.
Also, I haven't gone into the code yet, but the floating point
registers are not saved into the sigcontext so that they can be
inspected and modified as appropriate.
Thanks,
John
ps: I also noted that SA_RESTART is not documented in the man page
with the other mask bits, but instead is mentioned in a follow-on
statement. Just slightly misleading.
--
#include stdio.h
#include floatingpoint.h
#include signal.h
void fphand(int sig, int code, struct sigcontext *scp)
{
fprintf(stderr,"sig == %d\n",sig);
fprintf(stderr,"code== %d\n",code);
return;
}
void
setup()
{
int rc;
struct sigaction act, oact;
act.sa_handler = fphand;
act.sa_mask= 0;
act.sa_flags = SA_RESTART; /* not doc'd in man page */
rc = sigaction(SIGFPE, act, oact);
if (rc) {
perror("sigaction");
exit(1);
}
return;
}
double
doit(double x, double y)
{
return(x / y);
}
int
main()
{
double x,y,z;
fp_except_t mask = FP_X_DZ;
setup();
fpsetmask(mask);
x = 1.0;
y = 0.0;
z = doit(x,y);
printf("z has the value %f\n",z);
return((int) z);
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Berkeley DB question
Tony Finch wrote: User Joe [EMAIL PROTECTED] wrote: Is the berkeley db (or any other small db) multi user safe? Are there locks to maintain coherency of multiple processes access the same database files? The web pages for Berkeley DB 2 claim that it does (note version 2, not 1.85 as shipped with FreeBSD). http://www.sleepycat.com/. Also note the non-Berkeley license, if you're planning a contribution to FreeBSD. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
question: delay of a context - switch
Hi Dose anyone know how long a the kernel is busy with context switching (beetween two processes) ? Has anyone tested this yet? I estimate of about 7 usec duration for that, (on a Pentium 400) but I think that's to long. Regards Thomas To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Problem with fxp driver and 82559 cards
Large data transfers seem to cause the lockup. I know at least 1 netbsd person has reported similar problems with these new cards, (kern/7216). Has anyone seen problems like these? Any ideas? Hmmm...I've been using them in some machines here and haven't seen any problems. Strange. Do all of your systems have similar motherboards and CPU? The only thing that I can identify as a common factor, is that the PCI slots are on a riser card. One type is an NLX-form factor motherboard. The other is an industrial system with a Single Board Computer (SBC) and a passive backplain. Aside from the riser card, these machines are completely different. (IDE vs. SCSI, no other PCI devices, SCSI pci device, pentium vs pentium-II... onboard video/ethernet(in addition to the intel cards) vs nothing onboard...) However, we have at least one industrial-type system (with a different board/config) that works fine with these cards, though we didn't do the install with one. I'll try that tomorrow and report my findings. I doubt this is the case, but is the fxp driver different on the install floppy than on the post-install kernel / kernel-source? Same driver on floppy and installed kernel. Any suggestions as to what I should look into? It sounds like a motherboard chipset problem. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now works under New Midi Driver Framework with a Fine Timer)
On Wed, 7 Jul 1999 19:46:38 -0700 (PDT), Julian Elischer jul...@whistle.com said: julian With your scheme the clock needs to be always running at elevated speed. julian Possibly you might have a startup routine that turns on the elevated julian frequency, (basically does an 'aquire_timer0()' ) I would say that you julian would have more success in implementing your finetimer() by using julian aquiretimer0 than the other way around. I agree that acquire_timer0() would give more freedom to the ticks to callout. Then I tried figuring out how to manage multiple callouts using acquire_timer0(), which is something like below. Let C the callout queue, and c_i a callout. (0 = i I) Next define f(c_i) as the callout function of c_i, and dt_rem(c_i) the time span between c_(i-1) and c_i. (dt_rem(c_-1) is defined as zero) We use the time span to avoid traversing though the queue to update the time tags on the callouts. (footnote: I'd better write in TeX :-) Queueing a new callout c' to be made in t' involves a problem to find the maximum j (which is an integer, j = 0) satisfying a constraint t' \sum_(k=0)^(j) dt_rem(c_k) where the right hand side of the inequality is the time span after which the callout c_k is made. Then c' is inserted after c_j and new dt_rem(c_(j+1)) and dt_rem(c_(j+2)) are determined. Now we can acquire_timer0() with dt_rem(c_0). In clkintr(), we dequeue c_0 from C, and make a callout to f(c_0). Then acquire_timer0() is called once more with the new dt_rem(c_0). dt_rem(c_i) is the difference of callout times, so they need not be updated on every clkintr(). Although the computational cost in clkintr() is generaly O(1), the queueing cost is O(I). Not sure whether we can reduce it or not (will it really make a trouble?) How does it sound? Seigo Tanimura tanim...@naklab.dnj.ynu.ac.jp To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Bursting at the seams (was: Heh heh, humorous lockup)
jul...@whistle.com (Julian Elischer) writes: we already use the gs register for SMP now.. what about the fs register? I vaguely remember that the different segments could be used to achieve this (%fs points to user space or something) You can't extend the address space that way, segments are all parts of the single 4GB address space described by the page mapping. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Bursting at the seams (was: Heh heh, humorous lockup)
yeah I remembered how it all worked after I wrote that.. You'd think they'd eventually get the idea of letting the kernel have it's own 'cr3' and some TLBs eh? listenning intel? On 8 Jul 1999, Ville-Pertti Keinonen wrote: jul...@whistle.com (Julian Elischer) writes: we already use the gs register for SMP now.. what about the fs register? I vaguely remember that the different segments could be used to achieve this (%fs points to user space or something) You can't extend the address space that way, segments are all parts of the single 4GB address space described by the page mapping. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Bursting at the seams (was: Heh heh, humorous lockup)
jul...@whistle.com (Julian Elischer) writes: we already use the gs register for SMP now.. what about the fs register? I vaguely remember that the different segments could be used to achieve this (%fs points to user space or something) You can't extend the address space that way, segments are all parts of the single 4GB address space described by the page mapping. True, but you can reserve a part of the 4GB address space (say 128MB of it) for partitioning into tiny (say 8MB) address spaces (which are still flat, just small), for use by small processes, the idea being that all those small processes will than share a single page table without compromising on memory protection (the GDT is under full OS's control anyway), or the simplicity of a flat address space (virtual addresses still start at 0 and continue till the top of address space; the scheme is totally transparent.) patryk. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Heh heh, humorous lockup
dil...@apollo.backplane.com (Matthew Dillon) writes: pair-down the fields in both structures. For example, the vnode structure contains a lot of temporary clustering fields that could be removed entirely if clustering operations are done at the time of the actual I/O rather then before hand ( which leads to other problems related to low-memory deadlocks :-(... but assuming that could be fixed... ). Actually the vnode structure can be reduced in size quite a bit without affecting behavior. I analyzed this in a private mail to phk a few months ago, I can get the list of necessary changes out again if anyone is actually interested. The idea was to reduce the size to 128 bytes (on i386) so that the kernel malloc would do a reasonable job allocating the vnodes without too much overhead. IIRC it was very close. I had written code that allocated and deallocated vnodes dynamically (see http://www.hut.fi/~will/freebsd_vnfree0.diff for a non-malloc version with parameters adjusted to exercise the behavior quite heavily). It didn't seem like a very useful feature, though, because of fragmentation (even with the 'optimizing' zone allocator in the patch). Even if the kernel malloc would be usable, the only other common object that would typically use that memory would be ffs inodes, which are allocated and deallocated along with vnodes... This reminds me - the small patch I submitted to fix the v_id references still hasn't been commited (phk, if you're reading this, is there any specific reason for this?). To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Bursting at the seams (was: Heh heh, humorous lockup)
patr...@mycenae.ilion.eu.org (Patryk Zadarnowski) writes: You can't extend the address space that way, segments are all parts of the single 4GB address space described by the page mapping. True, but you can reserve a part of the 4GB address space (say 128MB of it) for partitioning into tiny (say 8MB) address spaces (which are still flat, just small), for use by small processes, the idea being that all those small processes will than share a single page table without compromising on memory protection (the GDT is under full OS's control anyway), or the simplicity of a flat address space (virtual addresses still start at 0 and continue till the top of address space; the scheme is totally transparent.) Yeah, I know, I've read Liedtke's original paper where he described the optimization in L3, that's fine for that specific purpose, but that wasn't what the thread was about. Unless I totally missed the point. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Replacement for grep(1) (part 2)
On Wed, 7 Jul 1999, Jamie Howard wrote: The FreeBSD, NetBSD, and OpenBSD manpage for grep says this: Grep understands two different versions of regular expression syntax: ``basic'' and ``extended.'' In GNU grep, there is no difference in available functionality using either syntax. Is this inaccurate or am I reading it wrong? I think that you are reading it wrong. It means If you have a task that can be performed in GNU grep using a regexp in one syntax, then the same task can also be performed in GNU grep using a regexp in the other syntax. It does not also mean ... and the regexps in the two syntaxes will be identical. For example, if your task is find lines that contain the characters open-parenthesesXclose-parentheses then you can use the basic RE '(X)' or the extended RE '\(X\)'. You can get the same functionality using either syntax, but the way you get that functionality will depend on which syntax you are using. --apb (Alan Barrett) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: docs/12377: doc patch for login_cap.
On Thu, 08 Jul 1999 00:03:10 +0100, Nik Clayton wrote: I have done. As far as I can tell, the submitter is saying Yes, the information I was looking for was in the manual page, but it (specifically, that the root account doesn't use the default entry) is buried as a throw away comment at the end of a long paragraph. No. The PR suggests a fix to a completely different paragraph, describing a different function. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now works under New Midi Driver Framework with a Fine Timer)
On Thu, 8 Jul 1999, Seigo Tanimura wrote: On Wed, 7 Jul 1999 19:46:38 -0700 (PDT), Julian Elischer jul...@whistle.com said: julian With your scheme the clock needs to be always running at elevated speed. julian Possibly you might have a startup routine that turns on the elevated julian frequency, (basically does an 'aquire_timer0()' ) I would say that you julian would have more success in implementing your finetimer() by using julian aquiretimer0 than the other way around. I agree that acquire_timer0() would give more freedom to the ticks to callout. Then I tried figuring out how to manage multiple callouts using acquire_timer0(), which is something like below. Let C the callout queue, and c_i a callout. (0 = i I) Next define f(c_i) as the callout function of c_i, and dt_rem(c_i) the time span between c_(i-1) and c_i. (dt_rem(c_-1) is defined as zero) We use the time span to avoid traversing though the queue to update the time tags on the callouts. (footnote: I'd better write in TeX :-) Queueing a new callout c' to be made in t' involves a problem to find the maximum j (which is an integer, j = 0) satisfying a constraint t' \sum_(k=0)^(j) dt_rem(c_k) where the right hand side of the inequality is the time span after which the callout c_k is made. Then c' is inserted after c_j and new dt_rem(c_(j+1)) and dt_rem(c_(j+2)) are determined. Now we can acquire_timer0() with dt_rem(c_0). In clkintr(), we dequeue c_0 from C, and make a callout to f(c_0). Then acquire_timer0() is called once more with the new dt_rem(c_0). dt_rem(c_i) is the difference of callout times, so they need not be updated on every clkintr(). Although the computational cost in clkintr() is generaly O(1), the queueing cost is O(I). Not sure whether we can reduce it or not (will it really make a trouble?) How does it sound? If I understand this correctly, you are suggesting that we program timer0 so that we only take interrupts when a finetimer is due to fire? If so, then it sounds very good. The idea of taking 6000+ interrupts/sec made me uneasy, even though most would return without doing any work. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
need a better solution as callback
hi to all, i have a freebsd installed with internet connection on my desktop pc and on my laptop as well. because i am traveling a lot between two countries, i'd like to make followings. - laptop dials to my desktop pc - laptop sends some command - desktop hangs up and dials to local isp - laptop dials also to a local isp - desktop sends a mail to me that means it is online (sends an ip address as well) - laptop logs in is it too much? any idea? thx geza _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: need a better solution as callback
Geza Fodor wrote: i have a freebsd installed with internet connection on my desktop pc and on my laptop as well. because i am traveling a lot between two countries, i'd like to make followings. You should be able to write some scripts which do this; theoretically, the some commands to my desktop pc bit can be an invocation of a background script which time-delays then initiates a PPP connection. - mark - laptop dials to my desktop pc - laptop sends some command - desktop hangs up and dials to local isp - laptop dials also to a local isp - desktop sends a mail to me that means it is online (sends an ip address as well) - laptop logs in is it too much? any idea? Mark Newton Email: new...@internode.com.au (W) Network Engineer Email: new...@atdot.dotat.org (H) Internode Systems Pty Ltd Desk: +61-8-82232999 Network Man - Anagram of Mark Newton Mobile: +61-416-202-223 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now worksunder New Midi Driver Framework with a Fine Timer)
On Thu, 8 Jul 1999 09:54:42 +0100 (BST), Doug Rabson d...@nlsystems.com said: dfr If I understand this correctly, you are suggesting that we program timer0 dfr so that we only take interrupts when a finetimer is due to fire? If so, dfr then it sounds very good. The idea of taking 6000+ interrupts/sec made me dfr uneasy, even though most would return without doing any work. Yes, that is what I am doing now. And some further discussion... t' \sum_(k=0)^(j) dt_rem(c_k) where the right hand side of the inequality is the time span after which the callout c_k is made. Then c' is inserted after c_j and new dt_rem(c_(j+1)) and dt_rem(c_(j+2)) are determined. Now we can acquire_timer0() with dt_rem(c_0). If t' is less than dt_rem(c_0) then we have no feasible j. This is the case in which we must reaquire_timer0() using t'. Then, after interting c', dt_rem(c_1) is updated to be (dt_rem(c_1) - (time elapsed since the last aquire_timer0())), so that c_1 can be armed later. There is one problem in this method. acquire_timer0() is only implemented for i386. We would need to write something equivalent for alpha... Seigo Tanimura tanim...@naklab.dnj.ynu.ac.jp To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Clipboard Daemon - thinking of writing one :)
On Thu, 8 Jul 1999, Mikhail Ramendik wrote: Hello! I am new to FreeBSD and Unix, but not new to programming and TCP/IP. I have noticed that there is no good clipboard system in FreeBSD. X has only a rudimentary clipboard, and outside X there is no clipboard that would be shared between programs... All this while Windows has a very interesting clipboard system that allows to paste as different types. Retrofitting this kind of thing will almost certainly be hard: Microsoft has the advantage of writing the toolkits used by their application developers, and getting to change the rules at any point in time. Similarly, Microsoft hasn't delivered the network services that you describe below, either. :) Microsoft also has the advantage of being able to liberally mix the operating system and application space. In UNIX-land, the entire windowing system and toolkits on top are replaceable, meaning that there is more flexibility, but fewer standards other than de-facto standards. Consider instead placing your work in the context of an object system (see below) such as GNOME or KDE. I am thinking of writing a Clipboard Demon (of course, free and documented and source and all) to try and tackle this problem. It's going to be a daemon working over IP, it will allow named clipboards so that by default each user has one clipboard, but a user can start several clipboards and/or share one over a network (ok, insecure, at least in first releases - but then, it can be nonsensitive info over a LAN). It will allow a program to export data into the clipboard in one or _several_ formats (MIME, of course), and then it will allow the importing program to choose the format it wants (a la Windows, but no OLE stuff here) and get the data in it. Security will be an issue here. The traditional way to do this kind of thing is in the context of an existing distributed system of some kind, relying in its services for connection management, data format management, etc. A few considerations you might want to examine would be single-host security (who owns what data, when can different things be copied, pasted -- xterm runs as root, your shell runs as you, your X server runs as root, etc, etc), multi-host security (cryptography, mapping users between systems, existing distributed authentication schemes (kerberos, for example), etc), and access control -- will you have shared clipboards? For example, a GUI text editor can export the text as native format, text, formatted text (RTF?), vector graphics (unsure what format would replace WMF here), bitmap. This same editor will paste the native by default, another editor will use the formatted text by default, etc. Note that it will work independently of X. So I can copy in Joe then paste to GIMP (as text), if both support the clipboard. I will probably have time for actual coding in August or September. But I want to work out the specs first, and to make sure it's needed at all ;) So, my questions are: - Whether this thing is, in your opinion, needed It sounds extremely useful. Network support is something that would be very nice to have, although you may be replicating work in distributed file systems. It might be worthwhile to consider whether an existing distributed file system might be a better time investment (Coda, AFS/Arla, etc) because it would provide a decent transport with a namespace, authentication, ACLs, etc. - Whether a similar solution already exists in the freenix world (perhaps in Linux?) Might want to look into the various distributed object models being considered (don't both the KDE and GNOME people have some interest in this?). I don't know much about them (KDE uses CORBA maybe?), but the chances are they have at least begun to address some of the complicated issues that you would need to look at. - How to handle big data? If a program exports a big graphic in several formats, that's a lot of data... Well, it can not actually send the data but only indicate it's available - but then we'd have to call back to receive the data, so the program would need to have a permanent connection with the daemon and listen to it, and the availability of data would cease when the program quits. Should I nevertheless include this behaviour as an option, to be decided by the exporting program? Now the newbie questions: - Where can I read a good text on writing FreeBSD daemons? - How can I choose a guaranteed free TCP port? www.iana.org IANA -- Internat Assigned Numbers Authority Yours in Christ, Mikhail Ramendik Moscow, Russia Your project sounds interesting, but I suspect that you may want to reconsider your approach. It might make more sense to have a distributed database or network accessible database capable of managing typed data, access control, authentication, etc, and then a local daemon that communicates with it, as well as to library hooks in applications via file system socket capable of passing local
Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now worksunder New Midi Driver Framework with a Fine Timer)
On Thu, 8 Jul 1999, Seigo Tanimura wrote: On Thu, 8 Jul 1999 09:54:42 +0100 (BST), Doug Rabson d...@nlsystems.com said: dfr If I understand this correctly, you are suggesting that we program timer0 dfr so that we only take interrupts when a finetimer is due to fire? If so, dfr then it sounds very good. The idea of taking 6000+ interrupts/sec made me dfr uneasy, even though most would return without doing any work. Yes, that is what I am doing now. And some further discussion... t' \sum_(k=0)^(j) dt_rem(c_k) where the right hand side of the inequality is the time span after which the callout c_k is made. Then c' is inserted after c_j and new dt_rem(c_(j+1)) and dt_rem(c_(j+2)) are determined. Now we can acquire_timer0() with dt_rem(c_0). If t' is less than dt_rem(c_0) then we have no feasible j. This is the case in which we must reaquire_timer0() using t'. Then, after interting c', dt_rem(c_1) is updated to be (dt_rem(c_1) - (time elapsed since the last aquire_timer0())), so that c_1 can be armed later. There is one problem in this method. acquire_timer0() is only implemented for i386. We would need to write something equivalent for alpha... The timer hardware on the alpha is essentially the same but the interrupts are wired up differently. I'm not sure how hard it would be to get timer0 working but I think it should be possible. The alphas tend to run the main clock quite fast (typically 1024hz) so the granularity of timing is better but probably not good enough for midi or pca. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now worksunderNew Midi Driver Framework with a Fine Timer)
On Thu, 8 Jul 1999 11:00:24 +0100 (BST), Doug Rabson d...@nlsystems.com said: There is one problem in this method. acquire_timer0() is only implemented for i386. We would need to write something equivalent for alpha... dfr The timer hardware on the alpha is essentially the same but the interrupts dfr are wired up differently. I'm not sure how hard it would be to get timer0 dfr working but I think it should be possible. I see. Then I can work on i386 first, and later on alpha. dfr The alphas tend to run the main clock quite fast (typically 1024hz) so the dfr granularity of timing is better but probably not good enough for midi or dfr pca. I agree. Seigo Tanimura tanim...@naklab.dnj.ynu.ac.jp To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Clipboard Daemon - thinking of writing one :)
You might also want to look a GNUstep ( www.gnustep.org ) as well. stef You wrote: - Whether a similar solution already exists in the freenix world (perhaps in Linux?) Might want to look into the various distributed object models being considered (don't both the KDE and GNOME people have some interest in this?). I don't know much about them (KDE uses CORBA maybe?), but the chances are they have at least begun to address some of the complicated issues that you would need to look at. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now worksunder New Midi Driver Framework with a Fine Timer)
dfr If I understand this correctly, you are suggesting that we program timer0 dfr so that we only take interrupts when a finetimer is due to fire? If so, dfr then it sounds very good. The idea of taking 6000+ interrupts/sec made me dfr uneasy, even though most would return without doing any work. 6000+ interrupts/sec is not many, unless it is done all the time. A 486/33 can handle about 5 (16000 for pcaudio + 3 * 11520 for sio's). There is one problem in this method. acquire_timer0() is only implemented for i386. We would need to write something equivalent for alpha... This is a serious problem. acquire_timer0() is currently disabled even for i386's when the i8254 is used for timecounting. This is not hard to fix (the hooks into clkintr() work even better with timecounters since it is not necessary to resynchronise clock interrupts after a state change), but an i8254 interrupt frequency of 16000 Hz is too fast to be used routinely if the i8254 is being used for timecounting (even if the CPU can keep up with the interrupts, the overflow heuristics in i8254_get_timecount() may break down). Other systems may have even more limitations on the timecounters. Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
/etc/skel vs /usr/share/skel
Hi folks, Do we still need /etc/skel in the hier(7) manpage and in BSD.root.dist? It looks to me like an hysterical raisin that should be taken out and shot. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now worksunder New Midi Driver Framework with a Fine Timer)
Somebody should study the abilities of the on-cpu APIC for this for pentium ff. machines. In message 199907081527.baa04...@godzilla.zeta.org.au, Bruce Evans writes: dfr If I understand this correctly, you are suggesting that we program timer0 dfr so that we only take interrupts when a finetimer is due to fire? If so, dfr then it sounds very good. The idea of taking 6000+ interrupts/sec made me dfr uneasy, even though most would return without doing any work. 6000+ interrupts/sec is not many, unless it is done all the time. A 486/33 can handle about 5 (16000 for pcaudio + 3 * 11520 for sio's). There is one problem in this method. acquire_timer0() is only implemented for i386. We would need to write something equivalent for alpha... This is a serious problem. acquire_timer0() is currently disabled even for i386's when the i8254 is used for timecounting. This is not hard to fix (the hooks into clkintr() work even better with timecounters since it is not necessary to resynchronise clock interrupts after a state change), but an i8254 interrupt frequency of 16000 Hz is too fast to be used routinely if the i8254 is being used for timecounting (even if the CPU can keep up with the interrupts, the overflow heuristics in i8254_get_timecount() may break down). Other systems may have even more limitations on the timecounters. Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Clipboard Daemon - thinking of writing one :)
On Thu, 8 Jul 1999, Mikhail Ramendik wrote: I have noticed that there is no good clipboard system in FreeBSD. X has only a rudimentary clipboard, and outside X there is no clipboard that would be shared between programs... All this while Windows has a very interesting clipboard system that allows to paste as different types. This is why Private Name Spaces are a good thing. They act like a file system (because they are a file system), they can be backed by a file system or whatever you wish (i've got both memory servers and file system servers) and they allow processes to create shared, private data to support such things as a clipboard. You don't need to write a special daemon, you just need to get private name spaces working on freebsd. I have a first piece in the v9fs file system, which is a memory file system but which is intended to support private name spaces in the future. Note that private name spaces work just fine over a network. ron To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Bursting at the seams (was: Heh heh, humorous lockup)
:yeah I remembered how it all worked after I wrote that.. :You'd think they'd eventually get the idea of letting the kernel have it's :own 'cr3' and some TLBs eh? : :listenning intel? This is intel we are talking about. Their mmu/cache technology is always a few years behind the times. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
RE: implementing a fs on a raw partition
If someone in the FS dept. would draw up a broad outline for FS implementation I hereby volunteer to flesh it out thoroughly and donate the end-product docs to the FreeBSD project. I am a professional UNIX (AIX/SOLARIS) programmer and fairly clueful kernel source peruser and tweaker, fully capable of producing professional quality technical documentation. I propose the following iterative process: 1) FS guru draws up broad scheme. 2) I flesh it out with resort to trial and error research, trying very hard to figure everything out for myself but ask precisely worded usually Y/N questions when I get good and stumped. 3) I submit draft for inspection by FS people, receive feedback. 4) I repair draft goto (2) Please refer only to 3.x 4.x methodology in the broad scheme. We'll make this a baseline and allow any deprecated stuff to properly atrophy into mummy dust. The purpose of this exercise is to produce a definitive procedure for coding new filesystems for use in the FreeBSD kernel. Benefits include speed of porting of 'foreign' FSes and feedback to the core group on implementation issues. Please CC al...@plantnet.com and al...@van.accessus.net in replies. The wife is 10 days overdue to deliver a baby and I'll (God, hopefully) be on vacation all next week and in sleep deprivation hallucinatory mode. -Original Message- From: Marc Tardif [SMTP:intm...@cam.org] Sent: Wednesday, July 07, 1999 9:22 PM To: freebsd-hackers@freebsd.org Cc: freebsd...@freebsd.org Subject: implementing a fs on a raw partition As I reading on filesystem algorithms and principles [bach 86 and mckusick 96], I am tempted to try my hand on a free partition. From my understanding, I should be using the partition as a character device for raw i/o in order to avoid the current filesystem overhead (/dev/rwd0s3). From that point, I've been using the code from /usr/src/sys/msdosfs in order to get something going at first... but this has shown to be an exhausting task. I keep running into dependencies and such which make it seem impossible to implement. Perhaps I have taken a wrong turn at Albuquerque, so I'd appreciate if anyone could give a hint to get me up and running. Thanks in advance, Marc [bach 86] The Design of the UNIX Operating System, Maurice J. Bach [mckusick 96] The Design and Implementation of the 4.4BSD Operating System, Marshall McKusick, Keith Bostic, Michael J. Karels, John S. Quarterman To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-fs in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
mbuf shortages
If a system runs out of mbufs can memory be claimed from elsewhere or is the system pretty much dead especially for networking related allocations. jayanth To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Problem with fxp driver and 82559 cards
However, we have at least one industrial-type system (with a different board/config) that works fine with these cards, though we didn't do the install with one. I'll try that tomorrow and report my findings. Though the cards seem to work post-install, they fail in the install program. I can transfer files to my hearts content using the ftp program... but if I go into the installer and try to transfer a distribution , it fails, locking in the same way. I'm talking with Intel to see if they have had similar problems. I read something in the source about the reciever has locked after garbage in the syncronization bits... could it be a similar problem with the new chip, perhaps exposed by certain types of equipment? Any suggestions as to what I should look into? It sounds like a motherboard chipset problem. It's a standard intel chipset... I'm getting a replacement BIOS to see if that makes a difference. Thanks, Jay To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: docs/12377: doc patch for login_cap.
Nope, I did read the docs, hence the patch to the manpage to make it stand out more clearly. I still am of the opinion that default should mean default for everyone. AFIK, there are no other fields in passwd that have different interpretations/defaults depending upon the UID. This is why I made my remarks about this being a violation of the principle of least surprise. My PR took the very conservative approach of just amplifying the documentation rather than making any funictional changes whatsoever. If a patch that make default the true default for all user and then explicitly set root's default class to 'root' would be accepted, I am willing to provide one. IMHO, this would be cleaner. The semantics of multiple default values boggles my mind. cheers, Adrian -- [ adr...@ubergeeks.com -- Ubergeeks Consulting -- http://www.ubergeeks.com/ ] On Tue, 6 Jul 1999, Sheldon Hearn wrote: On Mon, 05 Jul 1999 23:56:17 +0100, Nik Clayton wrote: I'm unfamiliar with the ins and outs of the login_cap system. Could someone who is versed in it please take a look at this PR (text included) and let me know whether or not the suggested patch is correct. Quite often, we receive requests to improve documentation that are born out of a failure to read that documentation correctly. I think this PR might be one of those cases. Have a look at the login_cap(3) manpage, into which I suspect the submitter may not have dug deeply enough: The functions login_getpwclass(), login_getclass() and login_getuserclass() retrieve the applicable login class record for the user's passwd entry or class name by calling login_getclassbyname(). On failure, NULL is returned. The difference between these functions is that login_getuserclass() includes the user's overriding .login_conf that exists in the user's home directory, login_getpwclass,() and login_getclass() restricts loookup only to the system login class database in /etc/login.conf. login_getpwclass() only differs from login_getclass() in that it allows the default class for user 'root' as root if none has been specified in the password database. Otherwise, if the passwd pointer is NULL, or the user record has no login class, then the system default entry is retrieved. Regards, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message Adrian -- [ adr...@ubergeeks.com -- Ubergeeks Consulting -- http://www.ubergeeks.com/ ] To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Problem with fxp driver and 82559 cards
However, we have at least one industrial-type system (with a different board/config) that works fine with these cards, though we didn't do the install with one. I'll try that tomorrow and report my findings. Though the cards seem to work post-install, they fail in the install program. I can transfer files to my hearts content using the ftp program... but if I go into the installer and try to transfer a distribution , it fails, locking in the same way. I'm talking with Intel to see if they have had similar problems. I read something in the source about the reciever has locked after garbage in the syncronization bits... could it be a similar problem with the new chip, perhaps exposed by certain types of equipment? What's the cable plugged into? -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Problem with fxp driver and 82559 cards
program... but if I go into the installer and try to transfer a distribution , it fails, locking in the same way. I'm talking with Intel to see if they have had similar problems. I read something in the source about the reciever has locked after garbage in the syncronization bits... could it be a similar problem with the new chip, perhaps exposed by certain types of equipment? What's the cable plugged into? We have tried: ATI switch (centrecom 3124tr) 10bT 3com SuperStack II (10/100) SMC TigerSwitch 10bT Same results on all of them. We've also tried setting media type to 10baseT/UTP in the 'ifconfig options' in sysinstall... no difference. Jay To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now works under New Midi Driver Framework with a Fine Timer)
this is problematic. you cannot add a new element before the pending firing because you can't tell how far into the present trigger you are. On Thu, 8 Jul 1999, Doug Rabson wrote: On Thu, 8 Jul 1999, Seigo Tanimura wrote: On Wed, 7 Jul 1999 19:46:38 -0700 (PDT), Julian Elischer jul...@whistle.com said: julian With your scheme the clock needs to be always running at elevated speed. julian Possibly you might have a startup routine that turns on the elevated julian frequency, (basically does an 'aquire_timer0()' ) I would say that you julian would have more success in implementing your finetimer() by using julian aquiretimer0 than the other way around. I agree that acquire_timer0() would give more freedom to the ticks to callout. Then I tried figuring out how to manage multiple callouts using acquire_timer0(), which is something like below. Let C the callout queue, and c_i a callout. (0 = i I) Next define f(c_i) as the callout function of c_i, and dt_rem(c_i) the time span between c_(i-1) and c_i. (dt_rem(c_-1) is defined as zero) We use the time span to avoid traversing though the queue to update the time tags on the callouts. (footnote: I'd better write in TeX :-) Queueing a new callout c' to be made in t' involves a problem to find the maximum j (which is an integer, j = 0) satisfying a constraint t' \sum_(k=0)^(j) dt_rem(c_k) where the right hand side of the inequality is the time span after which the callout c_k is made. Then c' is inserted after c_j and new dt_rem(c_(j+1)) and dt_rem(c_(j+2)) are determined. Now we can acquire_timer0() with dt_rem(c_0). In clkintr(), we dequeue c_0 from C, and make a callout to f(c_0). Then acquire_timer0() is called once more with the new dt_rem(c_0). dt_rem(c_i) is the difference of callout times, so they need not be updated on every clkintr(). Although the computational cost in clkintr() is generaly O(1), the queueing cost is O(I). Not sure whether we can reduce it or not (will it really make a trouble?) How does it sound? If I understand this correctly, you are suggesting that we program timer0 so that we only take interrupts when a finetimer is due to fire? If so, then it sounds very good. The idea of taking 6000+ interrupts/sec made me uneasy, even though most would return without doing any work. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd.Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: need a better solution as callback
Hi! I saw your posting on the HU list and was actually able to understand the Subject: line! (I guess it wasn't that difficult) It's fun to se the 'correct translation' so I could compare.. julian On Thu, 8 Jul 1999, Geza Fodor wrote: hi to all, i have a freebsd installed with internet connection on my desktop pc and on my laptop as well. because i am traveling a lot between two countries, i'd like to make followings. - laptop dials to my desktop pc - laptop sends some command - desktop hangs up and dials to local isp - laptop dials also to a local isp - desktop sends a mail to me that means it is online (sends an ip address as well) - laptop logs in is it too much? any idea? thx geza _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: 'rtfm' script
On Tue, 6 Jul 1999, Alex Zepeda wrote: On Tue, 6 Jul 1999, Brian F. Feldman wrote: RTFM isn't a newby-apparent term. Name it help(1). Sure it is. Some hapless newbie wanders into #FreeBDS on efnet, and asks an already answered question. Aside from a kick, and a possible ban, they're likely to be met with a chorus of rtfm, which in all likelyhood would prompt the inquisitive newbie to try and run rtfm. So the whole script is the punch line to a bad joke? I'm all for improving user documentation, but I keep getting mixed answers as to what this script is for. One answer is that it's so people will have something to do when they are so new and foolish as to believe that 'rtfm' is a command, the other answer is that this script/program/whatever is designed to do a bunch of help file searching that the user could (and probably should be) do themselves. I'd like to make a suggestion which might help both goals, and save some time. Instead of making a program to do the searching for the user, why not write a man page for 'rtfm' that describes the many resources available and how to use them? Then the actual rtfm command could be a short program that just calls up the man page. It's not as glamorous, but IMO it will be more useful. Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Problem with fxp driver and 82559 cards
From: Jay Kuri j...@oneway.com Date: 1999-07-08 11:19:01 -0700 To: David Greenman d...@root.com Subject: Re: Problem with fxp driver and 82559 cards Cc: hack...@freebsd.org In-reply-to: 199907081808.laa29...@implode.root.com Delivered-to: freebsd-hackers@freebsd.org X-Loop: FreeBSD.ORG program... but if I go into the installer and try to transfer a distribution , it fails, locking in the same way. I'm talking with Intel to see if they have had similar problems. I read something in the source about the reciever has locked after garbage in the syncronization bits... could it be a similar problem with the new chip, perhaps exposed by certain types of equipment? What's the cable plugged into? We have tried: ATI switch (centrecom 3124tr) 10bT 3com SuperStack II (10/100) SMC TigerSwitch 10bT Same results on all of them. We've also tried setting media type to 10baseT/UTP in the 'ifconfig options' in sysinstall... no difference. Some off-the-wall thoughts. I haven't followed this closely, but noticed the last few messages. Apologies if this is in the wrong ballpark. Have you tried a hub or a switch configured to stick with half-duplex? Also, some switches go dark when there's a change in port status, as might happen if a driver reinitializes the link. The switches are executing a spanning tree algorithm on the new port, looking for loops. If the switches can be configured to not do this (only needed for switch-switch connection), you might try that as well. (I'm not sure if the install issue is occuring soon after a boot, or is something else). Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Manager, CoreOS Networking| When crypto is outlawed, Apple Computer, Inc. | Only outlaws will have crypto. 2 Infinite Loop | Cupertino, CA 95014 | *-*---* To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Pictures from USENIX
just collecting URLs for people home pages might be an easier task perhaps ? It needs to look better than that. A list of URL's would not look like a staff page, it would look like a cheesy, uninteresting page of links. :) - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Pictures from USENIX
just collecting URLs for people home pages might be an easier task perhaps ? It needs to look better than that. A list of URL's would not look like a staff page, it would look like a cheesy, uninteresting page of links. :) still it can be a starting point. What success do you expect by asking people to prepare a resume! cheers luigi ---+- Luigi RIZZO, lu...@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) http://www.iet.unipi.it/~luigi/ngc99/ First International Workshop on Networked Group Communication ---+- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Pictures from USENIX
Jordan K. Hubbard writes: just collecting URLs for people home pages might be an easier task perhaps ? It needs to look better than that. A list of URL's would not look like a staff page, it would look like a cheesy, uninteresting page of links. :) besides, we don't all have, or even want to have, a home page. --- Gary Jennejohn Home - ga...@muc.de Work - ga...@fkr.dec.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
HELP!! Slice info disappeared
Hi hackers, I need your helps, please. I have two IDE drives. They have two slices for FreeBSD and Windows on each. Last night I tried to install Windows 95 on the first IDE drive where FreeBSD 3.1.0-Stable has installed. I executed fdisk program on MS-DOS and created an active slice to make it C: on the first drive. I successfully installed windows, and then rebooted FreeBSD. It's the beginning of my nightmare. On the boot time, kernel said there were no disklabel on the second IDE drive or something like that (sorry, I was so in panic that I didn't write them down on paper), and the system fall into single user mode. I checked the information for slices written on the second IDE, but it was almost the same as the first one. That is, each slices on second IDE have the same size on the first one. I didn't know what happened but I guess fdisk program changed the slice info not only for first IDE, but also the second one. I suppose (or wish) that the only slice information on the second IDE was overwritten, and the data on the second IDE are still there without any changes. Is there any way to retrieve the slice info? Any help is much appreciated. Thanks in advance, -- Kazukiyo UEDA To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Strange select/poll behaviour [EBADF inconsistancy]
Hi,
The following program returns an inconsistant rc/errno value.
Setting a bit corresponding to filedescriptor which is not open
is only found when it is less than 20. ie:
Some example output follows along with the program. This is being
run on a -current system. If I open a file on fd 1023 then I receive
EBADF all the way through which is what I expect. Our product depends
on this behaviour (no, don't ask)...
The man page specfies:
The first nfds descriptors are
checked in each set; i.e., the descriptors from 0 through nfds-1 in the
descriptor sets are examined.
I've seen that select seems to call poll, but I haven't trace
all the way through poll yet.
Any comments, critiques, or stupid user pointers are appreciated.
Thanks!
John
[3] : Bad file descriptor
[4] : Bad file descriptor
[5] : Bad file descriptor
[6] : Bad file descriptor
[7] : Bad file descriptor
[8] : Bad file descriptor
[9] : Bad file descriptor
[ 10] : Bad file descriptor
[ 11] : Bad file descriptor
[ 12] : Bad file descriptor
[ 13] : Bad file descriptor
[ 14] : Bad file descriptor
[ 15] : Bad file descriptor
[ 16] : Bad file descriptor
[ 17] : Bad file descriptor
[ 18] : Bad file descriptor
[ 19] : Bad file descriptor
[ 20] Timeout
[ 21] Timeout
[ 22] Timeout
[ 23] Timeout
[ 24] Timeout
[ 25] Timeout
#include stdio.h
#include unistd.h
#include errno.h
#include fcntl.h
#include sys/time.h
#include sys/stat.h
static struct timeval nowait_s = {0, 0}; /* poll, no wait */
static struct timeval wait_s = {0, 100}; /* poll, wait 1 sec*/
fd_set local_rfd;
fd_set local_wfd;
main()
{
intn;
struct timeval *tp;
intmax_fd = -1;
intcount;
intbytes;
intwait_time;
int i;
char * p;
char buffer[256];
fprintf(stderr,FD_SETSIZE = %d\n,FD_SETSIZE);
for(i=3;i40;++i)
close(i);
for(i=3;i40;i++)
{
bzero(local_rfd,sizeof(local_rfd));
bzero(local_wfd,sizeof(local_wfd));
FD_SET(i,local_rfd);
tp = wait_s;
n = select (200,local_rfd, 0, 0, tp);
if (n 0 )
{
sprintf(buffer,[%5d] ,i);
perror(buffer);
continue;
}
if (n == 0 )
{
printf([%5d] Timeout\n,i);
}
if (n 0)
{
if ( FD_ISSET(0, local_rfd) )
{
printf([0] READ\n);
}
if ( FD_ISSET(i, local_rfd) )
{
printf([%5d] READ\n,i);
}
}
}
}
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: docs/12377: doc patch for login_cap.
Sheldon, On Thu, Jul 08, 1999 at 10:23:06AM +0200, Sheldon Hearn wrote: I have done. As far as I can tell, the submitter is saying Yes, the information I was looking for was in the manual page, but it (specifically, that the root account doesn't use the default entry) is buried as a throw away comment at the end of a long paragraph. No. The PR suggests a fix to a completely different paragraph, describing a different function. OK. I've looked at this in more detail, and it seems as though two functions are being described in the manual page: There's login_getpwclass(). This function will use the root entry for the root user if it exists, before falling back to default. This is documented as such in the man page, so there are no problems there. In addition, there is login_getuserclass(). According to the PR, this also uses the root entry for the root user, if it exists, before falling back to default if it doesn't. Having now looked at (but not run) the code in src/lib/libutil/login_cap.c, I'm not convinced this last assertion in the PR is actually the case. It looks as if the code to use root instead of default first is in login_getpwclass(), but *not* in login_getuserclass(). So the PR is actually wrong about the text to add. That's fair enough. However, IMHO, the man page could be a bit clearer. Specifically, we have a paragraph that explains how defaults are looked up, and explicitly mentions the default class. We then have four intervening paragraphs, which do not relate to looking up the default entry. Finally, at the end of the fifth paragraph, is the information that login_getpwclass() will use a root entry first, before trying for default if the user being looked up is root. This last piece of information really belongs with the earlier paragraph (although it can be repeated later on). With that in mind, how about this patch (in conjunction with the patch to login.conf in the original PR, which just updates a comment)? --- login_cap.3.org Thu Jul 8 13:15:35 1999 +++ login_cap.3 Thu Jul 8 13:22:00 1999 @@ -147,6 +147,11 @@ with that name returned in the .Ar lc_class field. +In addition, if the referenced user has a UID of 0 (normally, +root, although the user name is not considered) then +.Fn login_getpwclass +will search for a record with an id of root before it searches +for the record with the id of default. .Pp The .Ar lc_cap @@ -231,6 +236,7 @@ .Fn login_getclass restricts loookup only to the system login class database in .Pa /etc/login.conf . +As explained previously, .Fn login_getpwclass only differs from .Fn login_getclass N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in 37514...@cs.colorado.edu To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Pictures from USENIX
I'm not asking any of you to prepare a resume - we're starting JUST with the core team bios and pictures here. :) - Jordan just collecting URLs for people home pages might be an easier task perhaps ? It needs to look better than that. A list of URL's would not look like a staff page, it would look like a cheesy, uninteresting page of links. :) still it can be a starting point. What success do you expect by asking people to prepare a resume! cheers luigi ---+- Luigi RIZZO, lu...@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) http://www.iet.unipi.it/~luigi/ngc99/ First International Workshop on Networked Group Communication ---+- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Pictures from USENIX
I'm not asking any of you to prepare a resume - we're starting JUST with the core team bios and pictures here. :) i knew you were not humans... cheers luigi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Strange select/poll behaviour [EBADF inconsistancy]
In article local.mail.freebsd-hackers/199907082010.qaa06...@bb01f39.unx.sas.com you write: Hi, The following program returns an inconsistant rc/errno value. Setting a bit corresponding to filedescriptor which is not open is only found when it is less than 20. ie: This is because initially, only 20 descriptors are allocated, and the system is quietly ignoring any descriptors over the allocated amount: if (uap-nd p-p_fd-fd_nfiles) uap-nd = p-p_fd-fd_nfiles; /* forgiving; slightly wrong */ This should be: if (uap-nd p-p_fd-fd_nfiles) return (EBADF); -- Jonathan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Strange select/poll behaviour [EBADF inconsistancy]
:This is because initially, only 20 descriptors are allocated, and :the system is quietly ignoring any descriptors over the allocated :amount: : :if (uap-nd p-p_fd-fd_nfiles) :uap-nd = p-p_fd-fd_nfiles; /* forgiving; slightly wrong */ : :This should be: : :if (uap-nd p-p_fd-fd_nfiles) : return (EBADF); : :-- :Jonathan Not unless you want to blow up virtually every program that uses select!!! Passing an nd parameter that is greater then the current number of descriptors is perfectly valid. It's setting a bit in the bitmask for one of those descriptors that should return EBADF! -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Strange select/poll behaviour [EBADF inconsistancy]
On Jul 07, 1999 at 02:33:19PM -0700, Matthew Dillon wrote: Not unless you want to blow up virtually every program that uses select!!! Passing an nd parameter that is greater then the current number of descriptors is perfectly valid. It's setting a bit in the bitmask for one of those descriptors that should return EBADF! Hmm, you're right. Arguably, it could return EINVAL. Actually, the man page documents this behavior, although it gets the 256 number wrong. If nfds is greater than the number of open files, select() is not guaran- teed to examine the unused file descriptors. For historical reasons, select() will always examine the first 256 descriptors. -- Jonathan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Strange select/poll behaviour [EBADF inconsistancy]
:Hmm, you're right. Arguably, it could return EINVAL. Actually, the :man page documents this behavior, although it gets the 256 number wrong. : : If nfds is greater than the number of open files, select() is not guaran- : teed to examine the unused file descriptors. For historical reasons, : select() will always examine the first 256 descriptors. : :-- :Jonathan This piece of the manual is justifying the fact that select() is not currently checking past the current number of open files -- which is how select() works now. The second part of that manual entry is just plain wrong: If you pass an nd value less then 256 it will only check that number of descriptors, it no longer examines a minimum of 256. It would definitely not be appropriate to return EINVAL. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Strange select/poll behaviour [EBADF inconsistancy]
On Thu, 8 Jul 1999, Matthew Dillon wrote: :Hmm, you're right. Arguably, it could return EINVAL. Actually, the :man page documents this behavior, although it gets the 256 number wrong. : : If nfds is greater than the number of open files, select() is not guaran- : teed to examine the unused file descriptors. For historical reasons, : select() will always examine the first 256 descriptors. : :-- :Jonathan This piece of the manual is justifying the fact that select() is not currently checking past the current number of open files -- which is how select() works now. The second part of that manual entry is just plain wrong: If you pass an nd value less then 256 it will only check that number of descriptors, it no longer examines a minimum of 256. So shouldn't someone correct it? I'll do it if noone else wants to. It would definitely not be appropriate to return EINVAL. I concur. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
dbm_* manpages for review
-hackers, Tim Singletary has written some man pages for the dbm_* functions in libc, which are currently undocumented -- we know they are written in terms of dbopen(), but it's nice to have them documented anyway. Could anyone who knows anything about DBM take a look at docs/12557 and let me know if they are correct? If they are, I'll commit them. Cheers, N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in 37514...@cs.colorado.edu To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: support for i386 hardware debug watch points
I just wondered if this should be integrated into ptrace(), so the various debuggers wouldn't have to know about it. It seems that would be the proper abstraction - hardware that supports it would have it - and the programs that used it wouldn't have to know anything special. I only have a passing knowledge of ptrace() - so, I may be totally wrong... - Dave Rivers - To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: need a better solution as callback
hi to all, i have a freebsd installed with internet connection on my desktop pc and on my laptop as well. because i am traveling a lot between two countries, i'd like to make followings. - laptop dials to my desktop pc - laptop sends some command - desktop hangs up and dials to local isp - laptop dials also to a local isp - desktop sends a mail to me that means it is online (sends an ip address as well) - laptop logs in is it too much? any idea? You can do better. Make the mgetty+sendfax port and run vgetty instead of mgetty. Set up your voice stuff (you'll need to copy the vgetty example config manually) and then create a dtmf.sh script. You can then dial your home machine on a handset, type in the correct DTMF sequence and have your machine connect to the 'net - you don't need to have direct dial access from your laptop :-) Ppp happily does this if you just give it a reasonable redial period frequency. thx geza -- Brian br...@awfulhak.orgbr...@freebsd.org http://www.Awfulhak.org br...@openbsd.org Don't _EVER_ lose your sense of humour ! br...@freebsd.org.uk To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Replacement for grep(1) (part 2)
Dag-Erling Smorgrav wrote: Assar Westerlund as...@sics.se writes: Dag-Erling Smorgrav d...@flood.ping.uio.no writes: + realpat = grep_malloc(strlen(pattern) + sizeof(^() + + sizeof()$) + 1); Why not just use asprintf? Doesn't matter, thsis code is gone in the latest version. You though the linux 'kernel of the day' was bad; now you have the FreeBSD 'grep of the minute' :) You guys need the infamous two-headed-editor from 'Dave-n-Val the two- headed programmer' at Weber State. It allows two programmers to edit the same file on two terminals; it displays the line of code the OTHER user's cursor is on in red and won't let your cursor on that line. ;^) -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC http://softweyr.com/ w...@softweyr.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now works under New Midi Driver Framework with a Fine Timer)
From: Julian Elischer jul...@whistle.com Subject: Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now works under New Midi Driver Framework with a Fine Timer) Date: Thu, 8 Jul 1999 11:23:42 -0700 (PDT) Message-ID: pine.bsf.3.95.990708112244.25198c-100...@current1.whistle.com julian this is problematic. julian you cannot add a new element before the pending firing because you can't julian tell how far into the present trigger you are. The workaround below would help it. The time elapsed since the last aquire_timer0() can be determined by latching the timer counter. From: Seigo Tanimura tanim...@naklab.dnj.ynu.ac.jp Subject: Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now worksunder New Midi Driver Framework with a Fine Timer) Date: Thu, 08 Jul 1999 18:40:23 +0900 Message-ID: 199907080940.saa26...@rina.naklab.dnj.ynu.ac.jp tanimura t' \sum_(k=0)^(j) dt_rem(c_k) tanimura tanimura where the right hand side of the inequality is the time span after which tanimura the callout c_k is made. Then c' is inserted after c_j and new dt_rem(c_(j+1)) tanimura and dt_rem(c_(j+2)) are determined. Now we can acquire_timer0() with dt_rem(c_0). tanimura tanimura If t' is less than dt_rem(c_0) then we have no feasible j. This is the case tanimura in which we must reaquire_timer0() using t'. Then, after interting c', dt_rem(c_1) tanimura is updated to be (dt_rem(c_1) - (time elapsed since the last aquire_timer0())), tanimura so that c_1 can be armed later. Seigo Tanimura tanim...@naklab.dnj.ynu.ac.jp To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Wrong comment in VM code?
At the beginning of the file vm_object.c, we have the following comment: The only items within the object structure which are modified after time of creation are: reference count locked by object's lock pager routine locked by object's lock But at the end of vnode_pager_setsize(), we modify the size field. So at least three items can be modified after creation. Am I right? Thanks for any help. -- Zhihui Zhang. Please visit http://www.freebsd.org -- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Simplifying Vinum (was: ufs/ffs resize?)
I think you'll find, once you get that far, that things are anything but trivial. I'm certainly open to suggestions, but consider: vinum -i /dev/something volumename Where does it insert it? What if the volume has more than one plex, which it will in the case of a mirror? OK, perhaps I was getting a little carried away here. :) Not if they're done well. I'm open to suggestions. Here are couple of possibilities: add commands cat, stripe and mirror: vinum cat /dev/da1h /dev/da2h vinum stripe /dev/da1h /dev/da2h /dev/da3h /dev/da4h vinum mirror /dev/da1h /dev/da2h vinum mirror /dev/da1h /dev/da2h /dev/da3h /dev/da4h These sound just fine to me! And what about the names? It seems tacky to have to write down the name that Vinum chooses. How about adding a name parameter, either implicitly or explicitly? For example, vinum cat myvol /dev/da1h /dev/da2h vinum cat -n myvol /dev/da1h /dev/da2h I also think that's a better proposal than mine, yes. - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: support for i386 hardware debug watch points
From: Thomas David Rivers riv...@dignus.com I just wondered if this should be integrated into ptrace(), so the various debuggers wouldn't have to know about it. It seems that would be the proper abstraction - hardware that supports it would have it - and the programs that used it wouldn't have to know anything special. I only have a passing knowledge of ptrace() - so, I may be totally wrong... - Dave Rivers - I think 'ptrace()' provides a natural interface for doing this. Under the covers, the 'ptrace()' calls are actually mapped to the corresponding procfs filesystem calls. While it is certainly possible to get at the registers using the more direct /proc/$pid/dbregs file, for historical reasons, the 'ptrace()' interface is probably the more expected method, and does not require issuing an open(), read(), write(), close() sequence. I've studied the code for 'gdb', and specifically the Linux support for their hardware debug registers. They use: ptrace (6, pid, offsetof (struct user, u_debugreg[DR_CONTROL]), debug_control_mirror); ptrace (6, pid, offsetof (struct user, u_debugreg[free_debug_register]), addr); Why they've hardcoded a '6' there I can't fathom, but it represents the PT_WRITE_U request to write directly into the child's user structure. Not only does this method require knowledge of x86 debug registers, but it also requires some knowledge of Linux internals. By providing a PT_[GET/SET]DBREGS request to 'ptrace()' in FreeBSD, which not by accident works identically to the existing PT_GET/SETREGS, and PT_GET/SETFPREG for getting/setting the general purpose and floating point processor registers, debuggers can focus on the hardware architecture, without having to be too concerned with obscure offsets of data within system data structures. In this respect, it actually results in less information that the programmer has to be aware of or keep track of. As far as providing a higher layer of abstraction, I must argue that these registers are primarily used only by debuggers, which must possess a very detailed kowledge of the underlying hardware by default. Thus, hiding the debug registers does not offer that much, however, exposing them to the debugger for complete control, can result in the complete debug support that is provided by the target architecture, as opposed to the subset that is supported across multiple architectures, that a higher level of abstraction implies. I suppose that in my view, I don't really see any difference in accessing the debug registers as accessing the general purpose registers or floating point registers, which is the model I used for this implementation. Also, this implementation currenly supports only those features that are available all the way back to the i386. Sorry for being so wordy. I should have provided some explanation for some of the design decisions that I made for this implementation when I posted my patches. I certainly hope that this work will be committed, because I think it adds a nice feature (once gdb supports it), especially for anyone who does non-trivial software development and debugging. Also, I must compliment the FreeBSD kernel folks ... the well designed internals of FreeBSD allowed a very clean implementation of this support. I did not have to do anything tricky to make it work. The framework was essentially there, I just had to plug in at the appropriate places in the kernel. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Simplifying Vinum (was: ufs/ffs resize?)
On Thursday, 8 July 1999 at 18:52:41 -0700, Jordan K. Hubbard wrote: I think you'll find, once you get that far, that things are anything but trivial. I'm certainly open to suggestions, but consider: vinum -i /dev/something volumename Where does it insert it? What if the volume has more than one plex, which it will in the case of a mirror? OK, perhaps I was getting a little carried away here. :) Not if they're done well. I'm open to suggestions. Here are couple of possibilities: add commands cat, stripe and mirror: vinum cat /dev/da1h /dev/da2h vinum stripe /dev/da1h /dev/da2h /dev/da3h /dev/da4h vinum mirror /dev/da1h /dev/da2h vinum mirror /dev/da1h /dev/da2h /dev/da3h /dev/da4h These sound just fine to me! And what about the names? It seems tacky to have to write down the name that Vinum chooses. How about adding a name parameter, either implicitly or explicitly? For example, vinum cat myvol /dev/da1h /dev/da2h vinum cat -n myvol /dev/da1h /dev/da2h I also think that's a better proposal than mine, yes. OK. This goes back to a message I wrote a long time ago. It's been a week since I committed the changes. Here's what we have (from vinum(8)): concat [-f] [-n name] [-v] drives Create a concatenated volume from the specified drives. mirror [-f] [-n name] [-s] [-v] drives Create a mirrored volume from the specified drives. stripe [-f] [-n name] [-v] drives Create a striped volume from the specified drives. The -s flag to mirror states whether to create concatenated or striped plexes for the mirror. Striped plexes always have stripes of 256 kB. For more details, RTFM. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
matcd on an SB16
I've been following a local Linux mailing list, and a couple of the
users there have been trying FreeBSD ('cos I'm giving a presentation on
it at a Linux user group meeting next month :-)
One of them has an SB16 with a CD-ROM drive. His attempts at installing
FreeBSD from that CD-ROM have met with abysmal failure:
$ Next came an install on my Pentium 60 (previously running Caldera-2.2)
$ - A total disaster no way despite 12 attempts to install, could I
$ get FreeBSD to actually initialise the sbpcd (freebsd calls it matcdc)
$ despite changing IO's, entering the manual configuration option etc
$ etc... it would not could not, find the cdrom so I had to abort the
$ install every time!!
Is the matcd driver known to work on FreeBSD 3.2 ? If not, does anyone
have any estimate of the amount of effort that'd be required to fix it?
- mark
Is the matcd driver known to work on FreeBSD 3.2 ? If not, does anyone
have any estimate of the amount of effort that'd be required to fix it?
- mark
Mark Newton Email: new...@internode.com.au (W)
Network Engineer Email: new...@atdot.dotat.org (H)
Internode Systems Pty Ltd Desk: +61-8-82232999
Network Man - Anagram of Mark Newton Mobile: +61-416-202-223
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
sigaction inconsistancy (here I go again)
Hi,
Running -current...
I'm trying to verify SIGFPE handling and am finding some
interesting issues. In the following test program, a divide
by zero is done and the SIGFPE delivered.
$ ./fp
sig == 8
code== 0
z has the value 1.00
It seems that from machine/trap.h the value of code should
have been:
/* codes for SIGFPE/ARITHTRAP */
#define FPE_FLTDIV_TRAP 0x3 /* floating/decimal divide by zero */
ie: 3 and not 0.
Also, I haven't gone into the code yet, but the floating point
registers are not saved into the sigcontext so that they can be
inspected and modified as appropriate.
Thanks,
John
ps: I also noted that SA_RESTART is not documented in the man page
with the other mask bits, but instead is mentioned in a follow-on
statement. Just slightly misleading.
--
#include stdio.h
#include floatingpoint.h
#include signal.h
void fphand(int sig, int code, struct sigcontext *scp)
{
fprintf(stderr,sig == %d\n,sig);
fprintf(stderr,code== %d\n,code);
return;
}
void
setup()
{
int rc;
struct sigaction act, oact;
act.sa_handler = fphand;
act.sa_mask= 0;
act.sa_flags = SA_RESTART; /* not doc'd in man page */
rc = sigaction(SIGFPE, act, oact);
if (rc) {
perror(sigaction);
exit(1);
}
return;
}
double
doit(double x, double y)
{
return(x / y);
}
int
main()
{
double x,y,z;
fp_except_t mask = FP_X_DZ;
setup();
fpsetmask(mask);
x = 1.0;
y = 0.0;
z = doit(x,y);
printf(z has the value %f\n,z);
return((int) z);
}
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: Berkeley DB question
Tony Finch wrote: User Joe j...@monk.via.net wrote: Is the berkeley db (or any other small db) multi user safe? Are there locks to maintain coherency of multiple processes access the same database files? The web pages for Berkeley DB 2 claim that it does (note version 2, not 1.85 as shipped with FreeBSD). http://www.sleepycat.com/. Also note the non-Berkeley license, if you're planning a contribution to FreeBSD. -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC http://softweyr.com/ w...@softweyr.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
