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 g
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 [E
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 instan
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
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
pre
>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 an
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
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
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, b
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 w
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 purp
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
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 m
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 "un
: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
In message <[EMAIL PROTECTED]>, Sergey Babkin writes:
>Jeremiah Gowdy wrote:
>> 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
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.
> There are absolutely no reasons for the card manufacturers to
> withhold thi
Jeremiah Gowdy wrote:
>
> 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 comp
In message <[EMAIL PROTECTED]>, Matt Dillon writes:
>Guys, on intel a simple conditional is going to be a whole lot
[less]
>expensive then a subroutine call no matter what, even if the
>conditional misses.
Sure, but it may be worth considering the effects on other platforms, present
a
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
>> stupi
: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 Unsubscr
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
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
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
> 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);
> >
>
> 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
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-hac
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
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
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 performa
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 t
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 PowerP
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
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 W
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 [
> 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 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
> driv
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 movi
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...
--
Christopher Nielsen
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the bod
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 cre
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
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 t
[ move this to -chat from -hackers ]
On Tue, Dec 19, 2000 at 12:25:43PM -0500, Dennis wrote:
> did you even read my comments, you blubbering moron? lol. I said NOTHING
> about theft. Zero. I guess you dont read english very well.
FYI - I bought LanMedia's cards instead of ETinc's because I fin
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
a
>
> 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
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
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
"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 t
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 secret
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 system
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 unsi
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
>> 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 fr
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
> > 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 !sigismembe
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 comp
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
> >>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 argua
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().
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.
* Dmitry Dicky <[EMAIL PROTECTED]> [001219 09:01] wrote:
>
> 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 shou
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>
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 s
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);
v
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
>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
just call it "installmoon" ;>
*chuckle*
/k
Warner Losh([EMAIL PROTECTED])@Mon, Dec 18, 2000 at 05:40:11PM -0700:
> In message <[EMAIL PROTECTED]> "Michael C . Wu" writes:
> : Would 20mb be a comfortable target for
> : "make buildsmallworld installsmallworld" ? The build would have to
> : be in
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 s
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
ht
"Christian Kuhtz" <[EMAIL PROTECTED]> writes:
> 1st channel:
> Maxtor 54098U8 UDMA4
> Kenwood CD-RUDMA2
>
> 2nd channel
> Maxtor 54098U8 UDMA4
> HP CD Writer 9300 UDMA2
>
> [...]
>
> ata0-master: ata_command: timeout waiting for intr
> ata0-m
Title: -==Ïðîãðàììà===Ðåãèîí==-
Åñëè Âû ïîëó÷èëè ýòî ïèñüìî âòîðè÷íî,
òî çàðàíåå ïðèìèòå íàøè èçâèíåíèÿ,
ýòî ñâÿçàíî ñ îøèáêàìè ñåðâåðà
Ïðîãðàììà Ðåãèîí
Óñëóãè ïðèåçæàþùèì â Ìîñêâó ||
Óñëóãè ïðèåçæàþùèì â Ìîñêâó
000 "Ïðîãðàììà Ðå
> -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 a
72 matches
Mail list logo
