RE: Floppy disk is full
-Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Kent Stewart Enviado el: Martes 19 de Diciembre de 2000 04:15 Para: Aoyama, Kieko Cc: '[EMAIL PROTECTED]' Asunto: Re: Floppy disk is full "Aoyama, Kieko" wrote: Hello, I am Kieko Aoyama. I am working at Compaq Computer K.K. in Japan. Please tell me the way of "getting boot.flp,fixit.flp,,kern.flp from FTP directory" But, I know the location of FTP directory,and I am going to getting these files to floppy disk(1.6MB). And I get the ERROR "You cannot write the file to disk". The OS that I'm using is Windows2000. And I am getting these files to drive A:. Please show me the way. You have to use fdimage from the /tools directory since they are images of the floppy. Kent --- Kieko AOYAMA@Compaq Computer K.K. Tel:03-5349-4491(4491) Fax:03-5349-7458 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message -- Kent Stewart Richland, WA mailto:[EMAIL PROTECTED] http://kstewart.urx.com/kstewart/index.html FreeBSD News http://daily.daemonnews.org/ 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
Ïðîãðàììà Ðåãèîí - ïîääåðæêà ðåãèîíàëüíîãî áèçíåñà â Ìîñêâå
Title: -==Ïðîãðàììà===Ðåãèîí==- Åñëè Âû ïîëó÷èëè ýòî ïèñüìî âòîðè÷íî, òî çàðàíåå ïðèìèòå íàøè èçâèíåíèÿ, ýòî ñâÿçàíî ñ îøèáêàìè ñåðâåðà Ïðîãðàììà Ðåãèîí Óñëóãè ïðèåçæàþùèì â Ìîñêâó|| Óñëóãè ïðèåçæàþùèì â Ìîñêâó 000 "Ïðîãðàììà Ðåãèîí" â ñîñòàâå 000 "Ñàëàíô-Ñåðâèñ" è 000 " Êîììóíèêàòèâíûé áèçíåñ-öåíòð" ðàáîòàåò íà ðûíêå óñëóã â Ìîñêâå ñ íîÿáðÿ 1994 ãîäà. Ñïåöèàëèçàöèÿ "Êîìïëåêñíûå óñëóãè ïðèåçæàþùèì â Ìîñêâó ïðåäñòàâèòåëÿì ðåãèîíàëüîãî áèçíåñà". Êëèåíòñêèé ñïèñîê íà ñåãîäíÿ âêëþ÷àåò ïðåäïðèÿòèÿ ðàçëè÷íûõ ôîðì ñîáñòâåííîñòè èç 16 ðåãèîíîâ ñòðàíû. Ïåðå÷åíü óñëóã ïîñòîÿííî ðàñøèðÿåòñÿ â çàâèñèìîñòè îò íàëè÷èÿ ïðîáëåì êëèåíòà.  íàñòîÿùåå âðåìÿ ìû ïðåäëàãàåì íà äîãîâîðíîé îñíîâå: 1 ÀÂÒÎÌÎÁÈËÜ ñ âîäèòåëåì â Ìîñêâå îò àýðîïîðòà è ïî ãîðîäó. 2 Áðîíèðîâàíèå ÃÎÑÒÈÍÈÖ. 3 ÁÈËÅÒÛ àâèà è æ/ä. 4 ÔÈÍÀÍÑÎÂÛÅ óñëóãè â Ìîñêâå. 5 ÂÈÇÛ â ëþáóþ ñòðàíó, çàêàç îòåëÿ è ìàøèíû. 6 VIP-ÎÒÄÛÕ. 7 Ïîêóïêà ÂÅÊÑÅËÅÉ áàíêîâñêèõ è ÎÀÎ "Ãàçïðîì". 8 ÏÐÅÄÑÒÀÂÈÒÅËÜÑÒÂÎ. 9 Çàêóïêà è ÎÒÏÐÀÂÊÀ òîâàðîâ â ðåãèîíû è ìíîãîå äðóãîå Åñëè Âû çàèíòåðåñîâàëèñü, òî îñòàâüòå çàÿâêó íà îçíàêîìëåíèå ñ äîãîâîðîì Àäðåñ: 125319, ã.Ìîñêâà, ×åòâåðòàÿ óëèöà 8-îãî Ìàðòà, ä. 3 || Äëÿ ïî÷òû: 125422, ã. Ìîñêâà, à/ÿ 3. Ôàêñ: (095) 152-93-40 || Òåë.: (095) 152-44-96, (095) 784-33-63, || e-mail: [EMAIL PROTECTED], || ñàéò: pregion.nm.ru Sent by "PersMail 2.1" (freeware) www.asuimp.ru - "Áèçíåñ-ñïðàâî÷íèêè è áàçû äàííûõ" www.e-kniga.ru - "Ýëåêòðîííàÿ áèáëèîòåêà" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ata weirdness
"Christian Kuhtz" [EMAIL PROTECTED] writes: 1st channel: Maxtor 54098U8 UDMA4 Kenwood CD-RUDMA2 2nd channel Maxtor 54098U8 UDMA4 HP CD Writer 9300 UDMA2 [...] snip ata0-master: ata_command: timeout waiting for intr ata0-master: ata_command: identify failed ad2: 39082MB Maxtor 54098U8 [79406/16/63] at ata1-master UDMA66 snip I bet your CD-ROM is incorrectly configured as master. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Need to edit VM tuning section in handbook, any special requirements?
On Mon, Dec 18, 2000 at 09:31:37PM -0800, Matt Dillon wrote: Is there anything special I need to do to edit a section in the handbook, or can I just commit it? A pass through -doc for review wouldn't be amiss. In general, this means that we make sure that none of the rules at http://www.freebsd.org/tutorials/docproj-primer/writing-style.html are broken. N -- Internet connection, $19.95 a month. Computer, $799.95. Modem, $149.95. Telephone line, $24.95 a month. Software, free. USENET transmission, hundreds if not thousands of dollars. Thinking before posting, priceless. Somethings in life you can't buy. For everything else, there's MasterCard. -- Graham Reed, in the Scary Devil Monastery To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
R: R: [tcpdump-workers] Re: R: [Ethereal-dev] Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!?
Hi. -Messaggio Originale- Da: Michael T. Stolarchuk [EMAIL PROTECTED] A: Loris Degioanni [EMAIL PROTECTED] Data invio: giovedì 14 dicembre 2000 16.39 Oggetto: Re: R: [tcpdump-workers] Re: R: [Ethereal-dev] Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!? ah, but the buffer sizes are fixed, and when the second buffer is full, packets are lost. yes, the tap runs at a higher prio than the buffer, but that doesn't alone guarnatee you won't see packet loss. (btw: i can confirm that behavior because i've had to work with it... i'm familiar with these effects since i wrote the nfrd sniffing and protocol decomposition stack) Or saying it another way: if you increase the buffer sizes, say to 1M each, and you're using, say completely saturdated 100Mb, which means 12.5Mbyes/sec, you have to get the copy out of bpf to process space in 1/12.5Mb/sec-80 Millisec. By copy rates, that's a long time. But, typical BPF sleep prioirities are LOW, which means that other processes complete with the bpf-processes restart to gain the processor. (As i recall, that has been fixed in a few architecutres). So if the bpf is run on a loaded machine (ie: a typical intrusion detection system) you still see periodic packet loss. That also partially explains why just test-sniffing the traffic isn't sufficient to test a platform for its ability to perform a decent job at ids... Ok, but I was testing only the capture performance, without any other process running at user level. In this situation, increasing the size of the buffer from 32k to 1M should give considerably better performance. This happens regularly in Windows, but very strangely, does not seem to happen in freebsd. `wintendo' sniffing is done in a way very similar to the one of BPF. With the same buffer size, the number of context switches is approximatly the same. I'm sorry, but i don't see that in your paper. Near the bottom of the paper it says that windoes sniffing buffers are 1M large. There are *very few* bpf's with buffers that large. In fact, in several kernels which i've used, multiple 1M kernel alloc's for space will cause the kernel to hang indefinitly (due to multiple 1M vm space allocations). i started my first reply with your text snippet noting the buffer size differences. Sorry, my phrase was not clear. I speak English like Tarzan... :-) I was trying to say that if you set the same buffer size in winpcap and in BPF, you will obtain approximately the same number of system calls, because the structure and the basic optimizations are the same. I say 'approximately' because this parameter is fixed in freebsd, while in windows it is possible to change it. However, standard buffer sizes are different, and I confirm that the buffer in windows is usually 1M. Notice that this size can be increased to bigger values without problems, and this seems to increase capture performance quite linearly. For example, on my Win2000 machine with 64M of RAM I am able to set a 40M kernel buffer, that grants very good performance when dumping to disk a 100Mbit ethernet. Also, in the same article, there's not attempt at trying to uncover the cause of performance difference, i don't see measurements of context switch rates, number of kernel system calls, nor number of interrupts. If i have missed it somewhere please let me know. Measuring these values can be quite complex, and we are not sure to do it properly in freebsd. My opinion, however, is that the discrepancy in performance is due not only to the number of system calls, but also to architectural differences, for example: - BPF is optimized to use small buffers, winpcap for big buffers. The circular buffer architecture of winpcap is more efficient with a 1M buffer. - DMA (or polling) transfers from the NIC driver to the RAM are handled more effectively by Windows than by freebsd. What i wish i had is a good tool to discover what is going on during the bpf packet loss. I was hoping (a few years back) to instructment a kernel, so that instead of being able to profile the sniffing process via statistical information about clock-tics, i could instead collect statistical about what was going on during bpf-packet-loss (ie: when the bpf second buffer is full). Turns out, that's hard to do, but i haven't forgotten how worthwhile such a hack would be... Yes, it would be very intersresting. Another interesting thing, in my opinion, would be the development of a standard benchmark to measure the performance of a capture architecture/program. This would allow to test precisely and impartially a capture system, and to obtain acceptable comparisons/references among different systems. Anyone interested at working on this? Loris. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD vs Linux, Solaris, and NT
Device Drivers -- I don´t like binary only device drivers. The code of an operating system is more complex than a driver. if a company does not want to publish the sourcecode, the should go away. You've lost all credibility here. Well supported device drivers should not require source. I'd prefer a commercial (preferably the manufacters) support other than some guy in the ural mountains who fixes things IF he can get a card with a problem and IF he can duplicate the problem and IF hes a good enough coder to get it done. case and point: How many of us are sitting on our hands waiting for DG to have time to fix the latest snafu in the if_fxp driver? You cant blame him for having a job and earning a living, but the fact is that only he has enough experience with the part to do the job. We all have source, but who wants to spend a couple of weeks learning the intricacies of a very complex part to fix what amounts to a very small bug? You NEED source in linux and freebsd and the like because manufacturers dont support their cards for these OSs and the drivers are a continuous work in progress. Drivers are fixed only AFTER a problem with a new revision part is encountered, which undermines a companies abiltiy to do its work and to have confidence that they will have a solution in the future. I'd take a driver disk with a binary driver with each shipment of cards ANY DAY over having to cross my fingers that the current FreeBSD driver works with them. Drivers written in linux and freebsd, for example, are often "guesses" of how things work because exact documents are not available. The concept that some programmer, as good as he may be, working in his spare time on a driver without full documentation is more desirable than code provided by the manufacturer is so short-sighted that is illustrates that the author has no concept of reality. "hacker mentality" is not mainstream. 98% of people dont have a clue what to do with source code. They want products that just work. Your recommendation, if you make such a recommendation regarding "source over binary", suits your own requirements and not that of your client or readers and shows very poor judgement. DB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD vs Linux, Solaris, and NT
In message [EMAIL PROTECTED], Dennis writes: Device Drivers -- I don´t like binary only device drivers. The code of an operating system is more complex than a driver. if a company does not want to publish the sourcecode, the should go away. You've lost all credibility here. We have a saying in Denmark, which I'm sure exist in as many forms as there are languages in the world: "A thief belive everybody steals." Dennis, considering the recorded history of your arguments in our mailing list archives, hearing you come out and praise closed source drivers for open source OS's rings very very hollow. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
recvfrom() and signals
Hello fellows,
I just faced with a problem of a strange (may be not documented)
recvfrom() behaviour.
The fragment of the code is:
...
signal(SIGALRM, timeouttrap);
alarm(10);
i = recvfrom(sock, buf, len, 0, from, fromlen);
printf("%d bytes received\n",i);
void timeouttrap(int sig)
{
printf(" %d", sig);
return;
}
I use non blocking socket and it receives data with no problems.
When alarm occures, the signal delivered to the process and alarm handler
prints a signal number. As I understand after this recvfrom should
return -1 and errno should be set to EINTR.
BUt, upon signal delivery (actually any signal, CHLD for example)
recvfrom() still hangs the program execution and awaits data.
However, man pages say that recvfrom() will return -1 if the call has been
interrupted.
Is this a system bug or just my misunderstanding?
Thank you in advance,
Dmitry.
--
**
("`-''-/").___..--''"`-._ (\ Dimmy the Wild UA1ACZ
`6_ 6 ) `-. ( ).`-.__.`)DataArt Enterprises, Inc.
(_Y_.)' ._ ) `._ `. ``-..-' Serpukhovskaja street, 10
_..`--'_..-_/ /--'_.' ,' Saint Petersburg, Russia
(il),-'' (li),' ((!.-' +7 (812) 3261780, 5585314
**
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re[2]: FreeBSD vs Linux, Solaris, and NT
Hello Dennis, Tuesday, December 19, 2000, 8:43:17 AM, you wrote: D You've lost all credibility here. Well supported device drivers should not D require source. I'd prefer a commercial (preferably the manufacters) D support other than some guy in the ural mountains who fixes things IF he D can get a card with a problem and IF he can duplicate the problem and IF D hes a good enough coder to get it done. I really don´t think so. A hardware manufacter can give out the source and provide support, too. We all can benefit of this, because some people will begin to optimize something. If there is a free operating system with sources, the drivers should be free, too. Developing an OS takes more knowledge than developing a driver. As I said, I won´t have the same lame situation as on windows. If there is something wrong, I will have to look at the sources, too. And it´s not very complex to compile something. And if something like (compile, make, make install) is too complex, I don´t know what to say anymore. However, I won´t accept binary-only drivers or apps in any form. It is and it will be possible in the feature to develop and distribute progs with sourcecode, especially device drivers. It is a risk, but no ris(c|k) no fun -) TRUST NO ONE. We have a great operating system here. Why should we blame it with binary-only files??? I won´t. -- Best regards, Borismailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Call for review:PECOFF(Win32 Execution format) module.
Hi, I want to commit pecoff module under sys/compat/. The code is at http://people.freebsd.org/~takawata/pecoff.tar.gz This is kernel part of PEACE(http://chiharu.haun.org/peace/),that is announced as NewFeature of NetBSD1.5. Currently one more kernel module is needed to use PEACE in FreeBSD. If there is no objection, I will commit it. Thanks. Takanori Watanabe a href="http://www.planet.sci.kobe-u.ac.jp/~takawata/key.html" Public Key/a Key fingerprint = 2C 51 E2 78 2C E1 C5 2D 0F F1 20 A3 11 3A 62 2A To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: recvfrom() and signals
On Tue, Dec 19, 2000 at 09:45:05AM -0800, Alfred Perlstein wrote: See the sigaction manpage and how one enable/disables system call restarts. He is setting the signal handler with signal(), which calls sigaction() without the SA_RESTART flag set, so it seems that should interrupt recvfrom(). It is possible that something is calling siginterrupt() somewhere which changes what signal() does? David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD vs Linux, Solaris, and NT
Device Drivers -- I don´t like binary only device drivers. The code of an operating system is more complex than a driver. if a company does not want to publish the sourcecode, the should go away. Dennis said: /* I didnt "praise" closed source. I said there is arguable reasoning behind preferring supported binary drivers that work over incomplete source drivers. Selecting an OS based solely on this criteria is just plain stupid. Drivers generally do not require changes unless they are buggy. And the general public is generally no capable of maintaining a card driver with intricate knowledge of the controllers, which is no simple task. We have a saying in the US. "communism failed because its very essence breeds mediocrity". Your inabiltity to understand a business model that includes protecting corporate-funded assets, when MOST of the world's corporations adhere exclusively to such a model, shows how little you know about business in general. Your stupidity is also is emphasized by the fact that no major manufacturer has supported drivers for freebsd. Intel wont even help by providing docs. Bravo. What a WIN for the freebsd community. You've done a tremendous job marketing your concept. */ Well spoken Dennis. I must agree. While the open source concept is great, and we would PREFER that companies release open sourced drivers, I would prefer a binary driver from the company over a driver that someone in the freebsd camp put together based on whatever reverse engineering he could pull off. Not that I don't appreciate the work of the people who write BSD drivers, the people who put time and effort into BSD drivers are some of my favorite people in the world, but it's terribly obvious that if a card or device is not documented, that the company is going to provide a better binary driver than what a BSD programmer could put together (okay, broad generalization, but I'll stand by it in most cases). The closed source business model still lives, and hardware manufacturers cannot see why they should have to give out their source code. They hardly see the need to provide drivers for non-Microsoft operating systems, much less open sourced drivers. I'm afraid we're not quite in the position to make demands on hardware companies. If we establish a relationship with them, and represent ourselves as respectable professionals, this will ease the transition, and perhaps someday after using the binary versions of their drivers, we ask them to open the source. The statement "if a company does not want to publish the sourcecode, the(y) should go away." is the most foolish thing I've heard in a long time. The first step in moving up the ladder is realizing what rung you're currently standing on. If FreeBSD were to "boycott" or intentionally fail to support any particular hardware, the only losers would be us. If the Linux kiddies want to be the rabid open sourcers, and make demands of big companies fine. If they succeed, so do we (open source to them is open source to us). :) Why should both communities look like rabid idiots ? We can play the more calm professional role, like we usually do, and take either binaries or open source. Eventually, hopefully, the hardware manufacturers will come around and open up the source code on drivers. But if you're the kind of guy who wouldn't use a newer faster FreeBSD Adaptec SCSI driver because it's binary only, then that puts you in a class of people I like to refer to as 'rabid open source idiots'. I prefer to use the best of both worlds. And try to think a little bit if you can, when it comes to hardware manufacturers, who certainly see them selves ALOT higher on the ladder than we are, perhaps honey will get you more driver support than vinegar. :) Jeremiah Gowdy Network Administrator Sherline Products To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: recvfrom() and signals
On Tue, 19 Dec 2000, David Malone wrote: On Tue, Dec 19, 2000 at 09:45:05AM -0800, Alfred Perlstein wrote: See the sigaction manpage and how one enable/disables system call restarts. He is setting the signal handler with signal(), which calls sigaction() without the SA_RESTART flag set, so it seems that should interrupt recvfrom(). Bzzt :-) Alfred's correct. Read the manpage for signal again. To Dmitry: Don't use antiquated signal. Use sigaction and don't set the SA_RESTART flag. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD vs Linux, Solaris, and NT
On 19-Dec-00 Dennis wrote: At 11:44 AM 12/19/2000, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Dennis writes: Device Drivers -- I don´t like binary only device drivers. The code of an operating system is more complex than a driver. if a company does not want to publish the sourcecode, the should go away. You've lost all credibility here. We have a saying in Denmark, which I'm sure exist in as many forms as there are languages in the world: "A thief belive everybody steals." Dennis, considering the recorded history of your arguments in our mailing list archives, hearing you come out and praise closed source drivers for open source OS's rings very very hollow. did you even read my comments, you blubbering moron? lol. I said NOTHING about theft. Zero. I guess you dont read english very well. Umm. Dennis, there's this part of English called "figurative language". It involves things like similes, metaphors, etc. I suggest you go read up on it. Things like poetry, humor, etc. really depend on you understanding how it works. Even elementary school English classses in the U.S. cover such language basics. I didnt "praise" closed source. I said there is arguable reasoning behind preferring supported binary drivers that work over incomplete source drivers. Selecting an OS based solely on this criteria is just plain stupid. Drivers generally do not require changes unless they are buggy. And the general public is generally no capable of maintaining a card driver with intricate knowledge of the controllers, which is no simple task. Drivers can require changes because hardware is buggy and doesn't live up to its specs as well. Also, the driver that comes no your disk is not bug free either. :) I still would trust a driver that comes from the company however as their coders have access to the docco. (At least, one would hope they do.) We have a saying in the US. "communism failed because its very essence breeds mediocrity". Your inabiltity to understand a business model that includes protecting corporate-funded assets, when MOST of the world's corporations adhere exclusively to such a model, shows how little you know about business in general. Hmmm. It seems you have gone off on a tangent here to scream and make yourself be heard. Your stupidity is also is emphasized by the fact that no major manufacturer has supported drivers for freebsd. Intel wont even help by providing docs. Bravo. What a WIN for the freebsd community. You've done a tremendous job marketing your concept. So that's why Intel provides free bound copies of their IA-64 books and PDF's of the other chip manuals, PXE manuals, etc. I guess all those data sheets I've seen Bill Paul pore over while working on his ethernet drivers were just figments of my imagination as well. Am I a thief because my company provides value added solutions without source to our enhancements on a freebsd platform? If you are insulted that other people are using your work without paying for it then it sounds like you dont fit in very well with the "open source" community Mr. Kamp. Well, since you didn't get Poul's idiom, here's the native US version: "It takes one to know one." His point being that your claim that the original poster had lost all credibility in your judgement is rather hypocritical. I don't think anyone in the BSD camp is upset by people using BSD commercially. We'd all be GPL bigots if we were. :) Really, the world does not hate you, and we are not all evil. DB -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: recvfrom() and signals
He is setting the signal handler with signal(), which calls sigaction() without the SA_RESTART flag set, so it seems that should interrupt recvfrom(). Bzzt :-) Alfred's correct. Read the manpage for signal again. Ahh - I was reading the source code and missed the ! in !sigismember(). I was thinking of people using alarm() to timeout recvfrom() using a sigsetjmp(), but you don't need the syscall to be interrupted for that. *less confused now* To Dmitry: Don't use antiquated signal. Use sigaction and don't set the SA_RESTART flag. Indeedy! David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD vs Linux, Solaris, and NT
On Tue, Dec 19, 2000 at 11:43:17AM -0500, Dennis scribbled: | | Device Drivers | -- | I don´t like binary only device drivers. The code of an operating | system is more complex than a driver. if a company does not want to | publish the sourcecode, the should go away. | | You've lost all credibility here. Well supported device drivers should not No, he is simply stating his opinion. In addition, a well supported should include both the source *and* the binary. At least one of the reasons would be that customers who have top of the line drivers may wish to customize the behavior of the hardware. | require source. I'd prefer a commercial (preferably the manufacters) Have you ever used Realtek stock drivers on Win32? Have you tried to find a Neomagic driver on Win2K? Have you tried to find a driver for Solaris? Let's even see you try to use the newest Intel fxp0 driver for win32 and lose old functions. | support other than some guy in the ural mountains who fixes things IF he | can get a card with a problem and IF he can duplicate the problem and IF | hes a good enough coder to get it done. | | case and point: How many of us are sitting on our hands waiting for DG to | have time to fix the latest snafu in the if_fxp driver? You cant blame him | for having a job and earning a living, but the fact is that only he has | enough experience with the part to do the job. We all have source, but who | wants to spend a couple of weeks learning the intricacies of a very complex | part to fix what amounts to a very small bug? Many of us do. | You NEED source in linux and freebsd and the like because manufacturers | dont support their cards for these OSs and the drivers are a continuous | work in progress. Drivers are fixed only AFTER a problem with a new | revision part is encountered, which undermines a companies abiltiy to do | its work and to have confidence that they will have a solution in the future. If you don't like it, please don't use it. | I'd take a driver disk with a binary driver with each shipment of cards ANY | DAY over having to cross my fingers that the current FreeBSD driver works | with them. They work perfectly. On my systems, I could not get a good Brooktree driver for Win32. FreeBSD works fine. My Intel 82559 cards work fine. The newest Win2K Orinoco Wavelan driver cannot do ad-hoc mode, | Drivers written in linux and freebsd, for example, are often "guesses" of | how things work because exact documents are not available. The concept that No, we read datasheets like everybody else. | some programmer, as good as he may be, working in his spare time on a | driver without full documentation is more desirable than code provided by | the manufacturer is so short-sighted that is illustrates that the author | has no concept of reality. In that case, why are you using it? | "hacker mentality" is not mainstream. 98% of people dont have a clue what | to do with source code. They want products that just work. Your Yes, FreeBSD just works. | recommendation, if you make such a recommendation regarding "source over | binary", suits your own requirements and not that of your client or readers | and shows very poor judgement. So does yours. -- +--+ | [EMAIL PROTECTED] | [EMAIL PROTECTED] | | http://peorth.iteration.net/~keichii | Yes, BSD is a conspiracy. | +--+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD vs Linux, Solaris, and NT
Your stupidity is also is emphasized by the fact that no major manufacturer has supported drivers for freebsd. Intel wont even help by providing docs. Bravo. What a WIN for the freebsd community. You've done a tremendous job marketing your concept. So that's why Intel provides free bound copies of their IA-64 books and PDF's of the other chip manuals, PXE manuals, etc. I guess all those data sheets I've seen Bill Paul pore over while working on his ethernet drivers were just figments of my imagination as well. I think he's refering to the 82559 manual. It is available from Intel to developers, but only with an NDA. For various reasons, I can't sign an NDA for that information without putting myself in legal jeopardy. That has always been true, but I was able to obtain the [now older] 82557 manual without an NDA due to a screwup at Intel - which allowed me to write the original fxp driver. Unfortunately, a few things have changed since then, especially in the SEEPROM area and the only method I have of fixing those problems these days is by reverse-engineering. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: StrongARM support?
On Mon, Dec 18, 2000 at 04:14:10PM -0800, Devin Butterfield scribbled: | "Michael C . Wu" wrote: | The most important decision now would be: | Should we concentrate on the PPC port first? Or should we go at each | port simultaneously? | | Well, if there are enough people with PCC's that are interested in | helping with the effort then perhaps pursuing the PPC port first would | make more sense. I don't have a PPC so I couldn't help out there... | | If the decision is to pursue a StrongARM port then you can count me in. I'm definitely interested in both StrongARM and PPC. (and so are very many people) My understanding is that FreeBSD *wants* a FreeBSD/ARM, but lack the resources/man-power to do so. I'd prefer to see an official decision on the above by someone (hint hint -core :)) though. -- +--+ | [EMAIL PROTECTED] | [EMAIL PROTECTED] | | http://peorth.iteration.net/~keichii | Yes, BSD is a conspiracy. | +--+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: StrongARM support?
I have been working for several months to port NetBSD to a new StrongArm platform. I currently am using the Intel Assabet as my development platform. Based on my experience with NetBSD, I think that I could be of assistance in initiating a FreeBSD port. I actually do most of my development unsing an Arm cross compliler on a FreeBSD platform. What does it take to start up a new mailing list for proting to the Arm? (Who do I need to contact?) If we can identify a handfull of people who are interrested, I think we could make some quick progress. Paul Becke To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
nfs root mount - nfsv2
I am setting up a base image for a couple of network services servers being nfs root mounted ontop of a netapp filer. When I traced a problem with ethereal i found (or the sniffer claimed) that the nfs version that's used is v2 not v3. Due to some nfsv2 limitations I would like to get the systems use nfsv3 which the netapp files fully supports. Can anyone possibly the developer of the nfs root part of the kernel or of the pxe loader (which loads the kernel via nfsv2) help me on this? Thank's in advance Andreas --- switch Andreas Brodmann Telecommunications Dept. Migros Aare To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: FreeBSD vs Linux, Solaris, and NT
There are a number of reasons why a manufacturer can not/will not release source code for a driver. A few that come to mind are: a) A device driver is a reflection of the hardware. Manufacturers in highly competitive markets could potentially be giving away trade secrets for their new wiz-bang technology by publishing the source code. b) Manufacturers license technology from other manufacturers for inclusion into their product. The license/NDA does not allow them to disseminate the information (either through source or documentation). I can completely understand their position. If *I* were doing business in a highly competitive marketplace, I would be VERY weary of publishing my proprietary information for my competitors to see. EXAMPLE: I have been trying to deal with ATI recently regarding my All-In-Wonder 128 and TV-Out. Although they have been *VERY* helpful in giving me example source and datasheets for the R128 chipset, they cannot give me the information on how to enable TV-Out. This is because the ImpactTV chipset on my AIW contains technology licensed from Macrovision, and for them (ATI) to release the information to me would breach their agreement with Macrovision and open them up to a nice fat lawsuit. I *MAY* have to try and get a license from Macrovision and then present my licensing info to ATI -- and even if I did, I would not be able to distribute the source for that component of the driver... (sigh) IMHO, we should more than happy if a manufacturer supplies us with drivers, even if they are in binary form. If they release the source code/datasheets for a device, fantastic. Personally, I'd rather have the driver for the latest piece of hardware than wait several years until they feel releasing the info wouldn't hurt them in the marketplace. - Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: StrongARM support?
"Michael C . Wu" wrote: On Mon, Dec 18, 2000 at 04:14:10PM -0800, Devin Butterfield scribbled: | "Michael C . Wu" wrote: | The most important decision now would be: | Should we concentrate on the PPC port first? Or should we go at each | port simultaneously? | | Well, if there are enough people with PCC's that are interested in | helping with the effort then perhaps pursuing the PPC port first would | make more sense. I don't have a PPC so I couldn't help out there... | | If the decision is to pursue a StrongARM port then you can count me in. I'm definitely interested in both StrongARM and PPC. (and so are very many people) My understanding is that FreeBSD *wants* a FreeBSD/ARM, but lack the resources/man-power to do so. I'd prefer to see an official decision on the above by someone (hint hint -core :)) though. It's mainly a matter of interest (interested, dedicated people) rather than an official decision. I would say "go for it", and if it comes about, then great. If not, oh, well. Patrick [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: StrongARM support?
Paul Becke wrote: What does it take to start up a new mailing list for proting to the Arm? (Who do I need to contact?) Jonathan Bressler is our postmaster ([EMAIL PROTECTED]). I've added him to this message in hopes that he sees this. I haven't seen much of him lately... Course, it's always better to just start work on the project, and the web pages, mailing lists, etc will follow. Patrick [EMAIL PROTECTED] P.S. If you don't hear anything back, let me know and I'll give him a call. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD vs Linux, Solaris, and NT
It seems Steve Shoecraft wrote: There are a number of reasons why a manufacturer can not/will not release source code for a driver. A few that come to mind are: a) A device driver is a reflection of the hardware. Manufacturers in highly competitive markets could potentially be giving away trade secrets for their new wiz-bang technology by publishing the source code. b) Manufacturers license technology from other manufacturers for inclusion into their product. The license/NDA does not allow them to disseminate the information (either through source or documentation). c. the driver is so embarrasing they wont show it to the world This is more common than you would belive :) EXAMPLE: I have been trying to deal with ATI recently regarding my All-In-Wonder 128 and TV-Out. Although they have been *VERY* helpful in giving me example source and datasheets for the R128 chipset, they cannot give me the information on how to enable TV-Out. This is because the ImpactTV chipset on my AIW contains technology licensed from Macrovision, and for them (ATI) to release the information to me would breach their agreement with Macrovision and open them up to a nice fat lawsuit. I *MAY* have to try and get a license from Macrovision and then present my licensing info to ATI -- and even if I did, I would not be able to distribute the source for that component of the driver... (sigh) Well, go read the GATOS project source, they know how to switch the TVout stuff at least it works on my AIW :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Open Hardware Initiative (was Re: FreeBSD vs Linux, Solaris, and NT)
Matt Dillon wrote: Yes, it's a pretty sad state of affairs. What annoys me the most is that companies actually believe they are protecting something when they don't make their device driver source or hardware documentation available. It has been well proven for years that the most withholding accomplishes for the vast majority of these device drivers is a slight delay--- perhaps a week or two, before competitors figure out what they've done. Pirates don't care... they want the binaries anyway, they aren't programmers. And the open-source community has always strictly adhered to copyright and license restrictions. So all these companies are doing is making life harder for themselves and for their products. Unnecessarily. The XFree folks have some godaweful stories about the crap they've had to wade through to get video manufacturers on-board. Some video manufacturers have figured it out, a lot haven't. [...] I think the time is right to reward companies that "get it". I propose that the way to do this is to create an "open hardware" trademark that can be used for marketing by companies that sell hardware for which they either provide sufficient documentation that a fully featured device driver can be written without reverse engineering, or for which they provide at least one open-source driver. The idea is to do for friendly hardware vendors what the "OSI certified" mark (www.opensource.org) does for open-source software. I wrote ESR about this, since it's something that would have fit in well with OSI's mission, but he declined to take it up, as OSI was fully committed. He did mention, however, that an OSI board member had tried this in the past, but suggested that perhaps now the time is right. I invite discussion on what the OHI (Open Hardware Initiative) requirements should be and how best to proceed. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Source code of the dynamic loader
Hello! I am interested in the internals of FreeBSD's dynamic loader; where in the src module should I look for the appropriate source code? Best Regards, Sven C. Koehler To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Workaround for boot problems
Hi, I have a Mylex DAC960PL card on which FreeBSD 4.2 Release did not boot. I checked the "Trouble.txt" file for suggestion to fix the problem. The advise did not help. But I was able to fix the problem by booting the system with DOS boot disk; executing the DOS utility as "fdisk /mbr". This created Master boot record on the Mylex hosted logical drive. Then I installed the system and intructed the installation process to allocate partition WITHOUT DEDICATING ENTIRE DRIVE and instructed NOT TO TOUCH THE BOOT RECORD. The system installed and booted properly. I have seen the same problem on other systems with different SCSI host adapters. This workaround always worked. I don't know why but I assume the incorrect drive geometry is detected by the FDISK editor. Faisal Ali Network Engineer. Global Services Twenty One Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: RE: FreeBSD vs Linux, Solaris, and NT
What you are saying certainly has credence. I worked for a Semiconducter manufacturer here in Arizona (Microchip) as a software engineer for a number of years. We *ALWAYS* published full information about our devices (datasheets, etc), and it never hurt us -- because we always kept moving forward into new technology. Rival companies often cut the top of chips off and "map" the chip to see what others are doing. Even if they try to implement a similar technology, it still takes months of design work, characterization, production masking, etc. By that time, we were nearly in production with our next-gen chipsets. The only time I can remember not publishing information was for our Keylog products, which required an NDA. It has been my expirience, though, that chipset manufacturers generally *DO* publish information about devices. A quick call and a bit of social engineering can usually get you the datasheets, or a development kit, if the information isn't on the web. It's when these devices are applied that things become "grey." Sometimes, the hardware combined with the software make up the "technology advance." Such was the case with our (Microchip's) Keylog products. It's been a number of years since I worked for them, so, I don't know if they have "opened" it up yet or not. Perhaps I'll have to re-think my position in the matter concerning releasing information if I was in a competitive market. If I've spent millions of dollars researching a given technology, I'd be hard-pressed to immediately turn around and publish that information when I produced the product. Perhaps that's why so many companies are putting patents on damn near everything these days. I'm not saying that NO drivers should be open-sourced. Personally, I'd like to see them all (I too feel that open-sourced software is often better than the manufacturers). However, for those companies wishing NOT to (for whatever reason), a binary driver will do. The open source zealots view that "everything" should be open is simply too severe. - Steve P.S. Funny that you should mention xfree and video drivers -- personally, I feel that video drivers should be in the O/S domain and not in the xfree domain... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Matt Dillon Sent: Tuesday, December 19, 2000 2:36 PM To: Steve Shoecraft Cc: 'Soren Schmidt'; [EMAIL PROTECTED] Subject: Re: RE: FreeBSD vs Linux, Solaris, and NT Yes, it's a pretty sad state of affairs. What annoys me the most is that companies actually believe they are protecting something when they don't make their device driver source or hardware documentation available. It has been well proven for years that the most withholding accomplishes for the vast majority of these device drivers is a slight delay--- perhaps a week or two, before competitors figure out what they've done. Pirates don't care... they want the binaries anyway, they aren't programmers. And the open-source community has always strictly adhered to copyright and license restrictions. So all these companies are doing is making life harder for themselves and for their products. Unnecessarily. The XFree folks have some godaweful stories about the crap they've had to wade through to get video manufacturers on-board. Some video manufacturers have figured it out, a lot haven't. It also annoys me that certain people who should know better still seem to believe that open-source programmers are somehow substandard verses their commercial counterparts. I have one thing to say to that: Most open source programmers *ARE* professional programmers in their day jobs. We aren't talking about 14 year old wannabees here. Sure, there are lots of kids playing around with open-source systems, but don't make the mistake of assuming that these are the ones doing most of the serious kernel work. Most of the important work gets done by serious people. The quality of the open-source work tends to be much, much, MUCH higher then the quality of the programming produced by commercial companies, mainly because open-source work is opened up to peer review and programmers are doing it for fun, without the pressures of due dates or idiot managers. Every piece of proprietary commercial code I've ever seen has mostly been crap, and I don't expect that to change anytime soon. The paranoia of many commercial companies is misplaced. There are many classes of systems that obviously shouldn't be open-sourced, such as commercial hosted systems (e.g. most website backends), and many major programs are chock full of third-party-licensed technology that can't be redistributed (e.g. Netscape 4.x and earlier). But there are just as many that obviously
Re: Open Hardware Initiative (was Re: FreeBSD vs Linux, Solaris, and NT)
I think the time is right to reward companies that "get it". I propose that the way to do this is to create an "open hardware" trademark that can be used for marketing by companies that sell hardware for which they either provide sufficient documentation that a fully featured device driver can be written without reverse engineering, or for which they provide at least one open-source driver. The idea is to do for friendly hardware vendors what the "OSI certified" mark (www.opensource.org) does for open-source software. You need to start by looking at www.open-hardware.org. Don't be put off by the Linux-centric look; most of the relevant people involved are pretty system-neutral. If you want a specific contact, start with Henry Hall [EMAIL PROTECTED]. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Workaround for boot problems
I have a Mylex DAC960PL card on which FreeBSD 4.2 Release did not boot. I checked the "Trouble.txt" file for suggestion to fix the problem. The advise did not help. Which advice in particular? I assume that you already had the adapter set to 2GB mode? You should also have verified that the drive geometry detected by sysinstall was correct (???/128/32); I suspect in your case that this was the problem. I don't know why but I assume the incorrect drive geometry is detected by the FDISK editor. That's correct; if there's garbage on the disk, or just bad geometry information, sysinstall gets it wrong. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Source code of the dynamic loader
sys/kern/kern_linker.c n Tue, 19 Dec 2000, Sven C. Koehler wrote: Hello! I am interested in the internals of FreeBSD's dynamic loader; where in the src module should I look for the appropriate source code? Best Regards, Sven C. Koehler To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message *-. | Andrew R. Reiter | [EMAIL PROTECTED] | "It requires a very unusual mind | to undertake the analysis of the obvious" -- A.N. Whitehead To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Writing Device Drivers
On Tue, 19 Dec 2000, Christopher Nielsen wrote: On 17 Dec 2000, Nat Lanza wrote: Nothing documented the current kernel, Not to be obtuse, but the source always documents the current kernel for any OS... Yes, so it must be a real pain to write drivers for a closed-source OS like WinNT. I bet it costs thousands just to be a _certified developer_ or something.. (Oops, off-topic, the computer made me do it) -- Torbjorn Kristoffersen [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: StrongARM support?
On Mon, Dec 18, 2000 at 03:12:35PM -0600, Michael C . Wu wrote: I would be quite interested. But do we have the resouces and the man-hours to handle IA-64/KA-64/PPC/Alpha/StrongARM at the same time? Agreed. Perhaps the first step would be to start a [EMAIL PROTECTED] mailing list? Then why start Yet Another(tm) mailing list for it as everyone has agreed it isn't time for that yet. However, imho we should finish the FreeBSD/PPC project first. The StrongARM is quite similiar to the PPC processors. If we get the loader and init working, the rest will be a breeze. The loader would be very different from PowerPC for any StrongARM development platform I'm aware of -- DNARD and CATS. Uh... you certainly seem to have forgotten about locore.s and pmap modules. They are not "a breeze". We could simply build a cross-gcc on ARM/Linux and the rest is making sure that everything compiles. How about concentrating effort on just _one_ new platform (ok, two -- ia64 and powerpc)??? The good thing is that we do not need SMP on FreeBSD/ARM/StrongARM. (PowerPC still needs SMP support though.) Yes and no. Depend ons what you're doing with the powerpc -- remember the most interest for FreeBSD/PowerPC to date has been embedded products and comm processors. They don't tend to be SMP boards. I really don't see running on Mac G3/4 as the driving reason -- that machine is just the reference and development platform. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: StrongARM support?
On Mon, Dec 18, 2000 at 04:14:10PM -0800, Devin Butterfield wrote: Well, if there are enough people with PCC's that are interested in helping with the effort then perhaps pursuing the PPC port first would make more sense. I don't have a PPC so I couldn't help out there... There is a PowerPC simulator as part of GDB 5.0. People seem to discredit simulators don't forget both the Alpha and IA-64 ports were done using simulators. At this point the only person I know of that *has* to have hardware are those working on the loader and/or device drivers (which we aren't to that point yet). -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: StrongARM support?
On Tue, Dec 19, 2000 at 12:56:58PM -0600, Michael C . Wu wrote: many people) My understanding is that FreeBSD *wants* a FreeBSD/ARM, but lack the resources/man-power to do so. I'd prefer to see an official decision on the above by someone (hint hint -core :)) though. Why are you looking to Core for this??? FreeBSD is the conglomerate of the community. If a set of developers come forward and work on a StrongARM port and it proves to be of good quality, it would become part of the CVS repo. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: syscall assembly
On Sat, Dec 16, 2000 at 12:13:32PM -0800, Bakul Shah wrote: May be people who know more about gcc will explain this better but I will speculate in any case! Assuming that 16 ... But I still question this optimization. Are there any stats on whether this 16 byte aligning improves performance? it certainly increases space use! Why isn't this discussion going on at [EMAIL PROTECTED]?? That is certainly where the people in the know on these issues are. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c)
On Mon, Dec 18, 2000 at 01:11:12PM -0600, Jacques A. Vidrine wrote: /* Case 1 */ /* Case 2 */ if (data) vs. free(data) free(data); Actually from an optimization standpoint, #1 can be worse (ie, harder on the processor). You've got a conditional jump there that is using branch prediction HW to track (which means there is some other conditional branch you're not, you're fetching both the taken and not take paths, etc... If the function call isn't expensive, #2 can be "faster". -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Optimizations (was: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c))
On Tuesday, 19 December 2000 at 16:01:52 -0800, David O'Brien wrote: On Mon, Dec 18, 2000 at 01:11:12PM -0600, Jacques A. Vidrine wrote: /* Case 1 */ /* Case 2 */ if (data) vs. free(data) free(data); Actually from an optimization standpoint, #1 can be worse (ie, harder on the processor). You've got a conditional jump there that is using branch prediction HW to track (which means there is some other conditional branch you're not, you're fetching both the taken and not take paths, etc... If the function call isn't expensive, #2 can be "faster". In which processors is a function call anywhere near as cheap as a conditional local branch? Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Optimizations (was: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c))
In message [EMAIL PROTECTED], Greg Lehey writes: In which processors is a function call anywhere near as cheap as a conditional local branch? Doesn't PPC have some cases where a leaf function is basically free? -s To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Optimizations (was: Why not another style thread? (was Re: cvscommit: src/lib/libc/gen getgrent.c))
In which processors is a function call anywhere near as cheap as a conditional local branch? U.AMD2901? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Optimizations (was: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c))
On Tuesday, 19 December 2000 at 16:01:52 -0800, David O'Brien wrote: On Mon, Dec 18, 2000 at 01:11:12PM -0600, Jacques A. Vidrine wrote: /* Case 1 */ /* Case 2 */ if (data) vs. free(data) free(data); Actually from an optimization standpoint, #1 can be worse (ie, harder on the processor). You've got a conditional jump there that is using branch prediction HW to track (which means there is some other conditional branch you're not, you're fetching both the taken and not take paths, etc... If the function call isn't expensive, #2 can be "faster". In which processors is a function call anywhere near as cheap as a conditional local branch? as all optimizations it's compiler dependent, and one case would be when the function call is removed by the compiler (inlined or the like) :) cheers luigi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD vs Linux, Solaris, and NT
Dennis wrote: I didnt "praise" closed source. I said there is arguable reasoning behind preferring supported binary drivers that work over incomplete source drivers. Selecting an OS based solely on this criteria is just plain stupid. Drivers generally do not require changes unless they are buggy. And And buggy they usually are. In some cases it's just unbelievable what kinds of morons write these drivers (if you want an example, look for the company named "Longshine"). We have a saying in the US. "communism failed because its very essence breeds mediocrity". Your inabiltity to understand a business model that includes protecting corporate-funded assets, when MOST of the world's corporations adhere exclusively to such a model, shows how little you know about business in general. The drivers are _not_ assets. When I buy a piece of hardware I very reasonably expect that it would come with drivers or at least the manual on how to write these. It's a part of the deal. There are absolutely no reasons for the card manufacturers to withhold this information, their hardware is their copyright protection device and source of profit. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Optimizations (was: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c))
Guys, on intel a simple conditional is going to be a whole lot expensive then a subroutine call no matter what, even if the conditional misses. Subroutine calls are very fast on a P6, but if they push anything on the stack at all beyond the return address they are not going to be as fast as a conditional. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Optimizations (was: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c))
:Guys, on intel a simple conditional is going to be a whole lot :expensive then a subroutine call no matter what, even if the I'm really batting 0 today on grammer. I of course meant... "whole lot LESS expensive". :-) -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD vs Linux, Solaris, and NT
In message [EMAIL PROTECTED], Sergey Babkin writes: Dennis wrote: I didnt "praise" closed source. I said there is arguable reasoning behind preferring supported binary drivers that work over incomplete source drivers. Selecting an OS based solely on this criteria is just plain stupid. Drivers generally do not require changes unless they are buggy. And And buggy they usually are. I would be very surprised to find *ANY* driver with absolutely *no* bugs. We have a saying in the US. "communism failed because its very essence breeds mediocrity". Your inabiltity to understand a business model that includes protecting corporate-funded assets, when MOST of the world's corporations adhere exclusively to such a model, shows how little you know about business in general. The drivers are _not_ assets. Drivers to a third party piece of hardware are arguably assets. If, for instance, I built a system very much like FreeBSD, but in which all of the network drivers got 15% better performance, the world would beat a path to my door. When it's your *own* hardware, of course, the hardware itself is where the money is, and making the drivers maximally convenient is the best strategy. (Of course, this can, in turn, reveal "trade secrets", but if the interface to your hardware is a trade secret, well, geeze.) When I buy a piece of hardware I very reasonably expect that it would come with drivers or at least the manual on how to write these. It's a part of the deal. Yup. There are absolutely no reasons for the card manufacturers to withhold this information, their hardware is their copyright protection device and source of profit. Yup. It's much easier for me to copy drivers than it is for me to copy hardware. Of course, I'm better with an editor than with a soldering iron, and I don't have an 18-micron chip fab in my basement; some of you may find that it's the other way around. -s To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD vs Linux, Solaris, and NT
:I would be very surprised to find *ANY* driver with absolutely *no* bugs. /dev/null ? :-) -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Writing Device Drivers
Christopher Nielsen wrote: On 17 Dec 2000, Nat Lanza wrote: Nothing documented the current kernel, Not to be obtuse, but the source always documents the current kernel for any OS... Aww come on man- that was just obtuse. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD vs Linux, Solaris, and NT
In message [EMAIL PROTECTED], Matt Dillon writes: :I would be very surprised to find *ANY* driver with absolutely *no* bugs. /dev/null ? It must have a bug, we got a support request once because of an error message. Something about a bit bucket... -s p.s.: ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Writing Device Drivers
Christopher Nielsen [EMAIL PROTECTED] writes: Not to be obtuse, but the source always documents the current kernel for any OS... If you believe that the source is always adequate documentation for kernel programming, especially in the Linux world, I have a bridge to sell that you might be interested in. --nat -- nat lanza - research programmer, parallel data lab, cmu scs [EMAIL PROTECTED] http://www.cs.cmu.edu/~magus/ there are no whole truths; all truths are half-truths -- alfred north whitehead To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Writing Device Drivers
In message [EMAIL PROTECTED], Nat Lanza writes: If you believe that the source is always adequate documentation for kernel programming, especially in the Linux world, I have a bridge to sell that you might be interested in. Is it open source? If so, I will be able to adapt it to my own purposes in a matter of minutes, right? That's what the guy on slashdot said about open source. :) Speaking of source not telling the naive user anything: I want VirtualPC to run FreeBSD. It runs NetBSD just fine, and Connectix is very, very, good about answering questions or fixing bugs... if you can isolate them. Would someone who understands boot blocks be interested in debugging, or helping me debug, why the FreeBSD boot loader isn't working on VPC? I'll happily contribute all the patches I have for making other devices work or, at least, work around their issues. ;) -s To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Writing Device Drivers
On 19 Dec 2000, Nat Lanza wrote: Christopher Nielsen [EMAIL PROTECTED] writes: Not to be obtuse, but the source always documents the current kernel for any OS... If you believe that the source is always adequate documentation for kernel programming, especially in the Linux world, I have a bridge to sell that you might be interested in. Part of my point is that the kernel source for linux is NOT sufficient documentation. However, I have found that in many cases, the source for FreeBSD and some other OSs (plan9) are sufficient documentation for kernel programming, but usually only for an experienced kernel programmer. -- Christopher Nielsen [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Optimizations (was: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c))
On Tue, Dec 19, 2000 at 06:36:06PM -0600, Peter Seebach wrote: In message [EMAIL PROTECTED], Greg Lehey writes: In which processors is a function call anywhere near as cheap as a conditional local branch? Doesn't PPC have some cases where a leaf function is basically free? Maybe, but free() is not a leaf function. -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c)
On Tue, Dec 19, 2000 at 04:01:52PM -0800, David O'Brien wrote: On Mon, Dec 18, 2000 at 01:11:12PM -0600, Jacques A. Vidrine wrote: /* Case 1 */ /* Case 2 */ if (data) vs. free(data) free(data); Actually from an optimization standpoint, #1 can be worse (ie, harder on the processor). You've got a conditional jump there that is using branch prediction HW to track (which means there is some other conditional branch you're not, you're fetching both the taken and not take paths, etc... If the function call isn't expensive, #2 can be "faster". There's more overhead than just the function call itself. For example, our free() will do some locking check for recursion beforing calling another function that actually does the work. -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD vs Linux, Solaris, and NT
At 18:47 19/12/00 -0800, you wrote: Sergey Babkin wrote: The drivers are _not_ assets. When I buy a piece of hardware I very reasonably expect that it would come with drivers or at least the manual on how to write these. It's a part of the deal. However, if the device requires software to take on part of the functionality (examples: WinModems, although I'm not sure whether it's the driver or the OS that's doing the work there. I also suspect some OpenGL cards may be like this), then the driver is more likely to be considered an asset. I was on the point of stepping in with a very similar opinion. While I'm deeply hacked off at Intel for not dropping the NDA on 82559 series 8, causing me to have to think twice about using them in a commercial product, or indeed about using Intel at all, I can see a situation where I do feel it is fair: A lot of the reason why 3dfx (rip), Nvidia et al. often feel they cannot release open source drivers is that a substantial proportion of what these products do takes place on the host processor. Large quantities of research go into the exact division of tasks between host processor and offload processor, hence a large amount of their competitive advantage is derived from the driver code. They cannot afford to release it. Furthermore, AGP represents a substantial bottleneck to them, the protocol by which they get information down it is also of great commercial significance. Asking for open source drivers in these cases is much like asking for open source firmware on the boards themselves, simply not going to happen. To conclude: Open source, preferred. Closed source, OK. No driver whatsoever, bad. Bad bad bad. Should this really still be on -hackers? Justin Wojdacki David Preece Aside: 82559/8, how does this affect BSDi's pre-installed rackmount boxes? Presumably it's all going to go a little tits-up when they start getting series 8 parts? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD vs Linux, Solaris, and NT
Aside: 82559/8, how does this affect BSDi's pre-installed rackmount boxes? Dunno. Presumably it's all going to go a little tits-up when they start getting series 8 parts? I was about to ask you to explain why this would be a problem, but I suppose you can't. :) Anyway, I haven't heard anything, but this could be an issue for BSD/OS, too, since the exp(4) driver is shipped to source license customers... -s To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD vs Linux, Solaris, and NT
At 21:54 19/12/00 -0600, you wrote: Presumably it's all going to go a little tits-up when they start getting series 8 parts? I was about to ask you to explain why this would be a problem, but I suppose you can't. :) I thought they were using intel 82559's and came with FreeBSD 4.x preinstalled... http://www.bsdi.com/products/pdfs/1200_series.qxd.pdf Anyway, I haven't heard anything, but this could be an issue for BSD/OS, too, since the exp(4) driver is shipped to source license customers... exp? fxp! Oh, I suppose it might be exp in BSD/OS, I dunno. -s David Preece To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
eepro100 dual port cards with failover ?
We need to use the dual Intel PRO/100+ dual port server adapter, and I wanted to know if FreeBSD supports them ? I guess that the card is a dual port (2 x RJ45) card and it uses only 1 IP for both ports and if one switch goes down it will automatically failure to the other port ? Is this at the driver level or at the hardware level ? (if anyone knows ) and if FreeBSD does not support them then can anyone recommend something similar ? thank you nathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
gcc builtin specs
When running the command gcc -v on FreeBSD 4.2-RELEASE, I get "Using builtin specs". On Linux, I get some path. How can I know which specs are used by the preprocessor, compiler, assembler and linker on FreeBSD then? PS. Should I have posted this question elsewhere? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Request for comments: ISA_PNP_SCAN() (long)
This is to propose a new ISA bus method to sys/isa/isa_common.c.
The new method is to enumerate PnP device instances matching the
specified PnP IDs. (Well, may be this is a kludge after all.)
device_t ISA_PNP_SCAN(device_t bus, struct isa_pnp_id *ids, int *n);
It will return the (n + 1)th instance of the given PnP IDs on the
specified ISA bus. You set -1 to n to obtain the first PnP instance
matching the given PnP IDs and can enumerate all matching instances
by calling ISA_PNP_SCAN() until it returns NULL.
I think this is useful for the following situation.
The ISA device drivers supporting PnP look like the following
in -CURRENT.
struct isa_pnp_id foo_ids[] = {
{ 0xNNN,"Foo bar" },
};
int
foo_probe(device_t dev)
{
if (ISA_PNP_PROBE(dev, foo_ids) == ENXIO)
return ENXIO;
...
}
ISA_PNP_PROBE() returns 0 if the ISA device instance dev has the
matching PNP ID, returns ENXIO if the ID doesn't match, and returns
ENOENT if the device instance doesn't have a PNP ID (because it was
created by the isahint driver, based on /boot/device.hints). This
way, the driver can work correctly with both the "hint" (non-PnP) device
instance and the PnP device instance.
The trouble is that we always need to have hints for this driver in
/boot/device.hints for those systems without a PnP BIOS. Then, the
isahint driver will create a device instance. The pnpbios driver will
create a PnP device instance separately if the PnP BIOS exists and
reports the presence of a device.
Problem 1:
In -CURRENT the non-PnP device instance is probed first. If this is
successful, it will become available to the system as the 'foo0'
device. Probe on the PnP device instance will fail in this case
because the resources for this device has already been claimed by the
non-PnP device instance, and the user will see erroneous boot message
"unknown: PNP cannot assign resources".
Problem 2:
If the non-PnP device instance fails probe (because device hints are
wrong), the PnP device instance will succeed (because its resource
description is supposed to be correct). The PnP device instance will
become available in the system as 'foo1', rather than 'foo0'. This is
because the non-PnP device instance wasn't deleted after its probe
failed.
To avoid the second problem, we may prepare two separate drivers for
non-PnP and PnP device instances as follows.
/* the driver for non-PnP device instance */
driver_t foo_driver = {
"foo",
foo_methods,
sizeof(struct foo_softc),
};
int
foo_probe(device_t dev)
{
/* proceed only if this is not a PnP device instance */
if (ISA_PNP_PROBE(dev, foo_ids) != ENOENT)
return ENXIO;
...
}
/* the driver for PnP device instance */
driver_t foopnp_driver = {
"foopnp",
foopnp_methods,
sizeof(struct foo_softc),
};
int
foopnp_probe(device_t dev)
{
/* proceed only if this is a PnP device instance */
if (ISA_PNP_PROBE(dev, foo_ids) != 0)
return ENXIO;
...
}
This way, we will have 'foo0' when the PnP BIOS is not present or
device hints for the non-PnP device instance are correct. Otherwise,
we will have 'foopnp0'.
But, we will still have the first problem: "unknown: PNP can't
assign resources."
If we have ISA_PNP_SCAN() above, we can do something like below to
solve this problem.
/* the driver for non-PnP device instance */
driver_t foo_driver = {
"foo",
foo_methods,
sizeof(struct foo_softc),
};
int
foo_probe(device_t dev)
{
device_t bus;
device_t pnpdev;
int unit;
int i;
/* proceed only if this is a non-PnP device instance */
if (ISA_PNP_PROBE(dev, foo_ids) != ENOENT)
return ENXIO;
bus = device_get_parent(dev);
unit = device_get_unit(dev);
/* fail if we have a PnP sibling */
i = unit - 1;
pnpdev = ISA_PNP_SCAN(bus, foo_ids, i);
if (pnpdev device_get_state(pnpdev) == DS_NOTPRESENT)
return ENXIO;
...
}
/* the driver for PnP device instance */
driver_t foopnp_driver = {
"foopnp",
foopnp_methods,
sizeof(struct foo_softc),
};
int
foopnp_probe(device_t dev)
{
/* proceed only if this is a PnP device instance */
if (ISA_PNP_PROBE(dev, foo_ids) != 0)
return ENXIO;
...
}
The non-PnP device instance will fail, regardless of device hints, if
a PnP device instance for this device exists on this ISA bus. Then
we will always have 'foopnp0' if the PnP BIOS reports the pretense of
this device. The non-PnP device instance will succeed, as 'foo0',
only if the PnP BIOS doesn't exist and device hints are correct.
This way, we are now clear of the two problems described above.
We can collapse the device methods for the two drivers into one.
driver_t foo_driver = {
"foo",
foo_common_methods,
sizeof(struct
Re: StrongARM support?
David O'Brien wrote: On Mon, Dec 18, 2000 at 03:12:35PM -0600, Michael C . Wu wrote: I would be quite interested. But do we have the resouces and the man-hours to handle IA-64/KA-64/PPC/Alpha/StrongARM at the same time? Agreed. Perhaps the first step would be to start a [EMAIL PROTECTED] mailing list? Then why start Yet Another(tm) mailing list for it as everyone has agreed it isn't time for that yet. I don't think that "everyone" had reached any such agreement. It would seem to me that there is sufficient interest in FreeBSD/StrongARM that such a project is certainly worth pursuing. A mailing list would definitely be helpful to coordinating the project, gaining additional support for the project, and it would also serve to keep all the chatter off of -hackers. We could simply build a cross-gcc on ARM/Linux and the rest is making sure that everything compiles. How about concentrating effort on just _one_ new platform (ok, two -- ia64 and powerpc)??? Well I certainly would agree that we should concentrate effort on just one or two new platforms. If there is more interest in a PPC or ia64 port than in a StrongARM port, then it would make more sense to concentrate on those. However, if there is more interest in StrongARM now, and hence people willing to working on it *now* and bring it to life, then pursuing a StrongARM port would make more sense. I for one am interested in helping put FreeBSD on a StrongARM. :) -- Regards, Devin. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: StrongARM support?
On Tue, 19 Dec 2000, Michael C . Wu wrote: many people) My understanding is that FreeBSD *wants* a FreeBSD/ARM, but lack the resources/man-power to do so. I'd prefer to see an There is a german saying "Schuster, bleib bei Deinen Leisten", which means something like "Only do, what you are good at". FreeBSD is good at the i386 side. Crossplatform is not really one of FreeBSD's strongest sides. Thats where NetBSD is *the* player. And there is a port to that Compaq ipaq thingy almost finished. And to RiscPC and DNARD (Shark) and CATS and Acorn A7000 and some intel developer boards, just to mention (Strong)ARM based systems supported by NetBSD. At the end a FreeBSD port will be based on the NetBSD port. Why should we split the BSD camp even more? But thats just my humble opinion. Btw. I run FreeBSD on my PC and NetBSD on my Shark. So, I do know and love both sides. -- Tom To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
