On Fri, 2 Jun 2000, Mike Smith wrote:
> > > > Typically, a driver may want to order some operations and also not break
> > > > post buffering each time a write is performed. It may for example want to
> > > > order some operations, but not flush all writes immediately. I didn't see
> > > > how
> > > Typically, a driver may want to order some operations and also not break
> > > post buffering each time a write is performed. It may for example want to
> > > order some operations, but not flush all writes immediately. I didn't see
> > > how to tell bus about that.
> >
> > The bus_space_ba
On Sun, 28 May 2000, Mike Smith wrote:
> > Speaking about bus_space_*(): Does it make the thing follow the PCI
> > ordering rules? Very probably not since it is impossible on some systems.
>
> There's no attempt to do this, no. However, it's possible to implement
> this if there's a need.
>
On Tue, 30 May 2000, Mike Smith wrote:
> This is still pretty straightforward, actually. Your problem is that
> you're looking at an API with *more* functionality, and you need to
> incorporate the superset. You'll typically find that everything your
> Linux driver does can be handled with a wra
> >> >A good bus abstraction lets you care as much or as little as necessary.
> >> >The NetBSD framework (which we use) allows you to do this.
> >>
> >> The best "portable" coding method is with memory-mapped registers, which
> >> seems to have been omitted from this "implementation", which is
At 08:32 AM 5/30/00 -0700, you wrote:
>> At 06:36 PM 5/27/00 -0700, Mike Smith wrote:
>> >> Existing bus abstractions tend to let think that the same software
driver
>> >> can deal with different buses, bridges or IO methods without having to
>> >> care about how these things actually behave, nota
> At 06:36 PM 5/27/00 -0700, Mike Smith wrote:
> >> Existing bus abstractions tend to let think that the same software driver
> >> can deal with different buses, bridges or IO methods without having to
> >> care about how these things actually behave, notably regarding buffering
> >> and ordering
> some people need more density than your obviously trivial needs, and the
> "new" bus-oriented implementation makes writing drivers with complex
> controllers much more difficult than need-be.
Speaking from some experience dealing with what would have to be
considered "complex" controllers, thi
Hi Dennis,
I can see that you disagree with some of the design decisions that have been
made. However, your tone makes that people will not listen to what you say,
but hammer into your person instead.
I'm not quite sure what you are trying to achieve by trampling all over
people's shoes like thi
In message <[EMAIL PROTECTED]> Dennis writes:
: The best "portable" coding method is with memory-mapped registers, which
: seems to have been omitted from this "implementation", which is the gripe
: here.
SYS_RES_MEMORY does exactly this. What are you talking about? I'm
using this in 5 differe
On Mon, 29 May 2000, Dennis wrote:
> At 06:36 PM 5/27/00 -0700, Mike Smith wrote:
> >> Existing bus abstractions tend to let think that the same software driver
> >> can deal with different buses, bridges or IO methods without having to
> >> care about how these things actually behave, notably re
erformance bus architecture is sad.
> >That you take it out on the people reading -current is beyond sad.
> >If you can't behave like an adult shut up and go away.
>
> I understand it, and I think it sucks. The world is going to object
> oriented languages to make programming
In message <[EMAIL PROTECTED]>, Dennis writes:
>>Uhm, the very fact that you are too simple-minded to understand the
>>new, flexible, structured, high-performance bus architecture is sad.
>>That you take it out on the people reading -current is beyond sad.
>>If you can't behave like an adult s
At 07:30 PM 5/27/00 -0400, Jeroen C. van Gelderen wrote:
>Dennis wrote:
>>
>> At 09:54 AM 5/27/00 +0200, John Hay wrote:
>> >> In message <[EMAIL PROTECTED]> Dennis writes:
>> >> : My 4.0 system doesnt probe ISA devices on my system.
>> >> :
>> >> : Whats the trick? Is there a config requirement
At 06:36 PM 5/27/00 -0700, Mike Smith wrote:
>> Existing bus abstractions tend to let think that the same software driver
>> can deal with different buses, bridges or IO methods without having to
>> care about how these things actually behave, notably regarding buffering
>> and ordering rules. Thi
At 03:57 PM 5/27/00 -0400, Bill Fumerola wrote:
>On Sat, May 27, 2000 at 03:51:24PM -0400, [EMAIL PROTECTED] wrote:
>
>> YesWhose brainstorm was it to use the new convoluted bus nonsense in
>> FreeBSD 4.0? Clearly someone who never wrote a driver with a complex
>> controller with indexed memor
> Speaking about bus_space_*(): Does it make the thing follow the PCI
> ordering rules? Very probably not since it is impossible on some systems.
There's no attempt to do this, no. However, it's possible to implement
this if there's a need.
> Typically, a driver may want to order some operatio
Doug Rabson wrote:
> On Sat, 27 May 2000, Dennis wrote:
> > At 09:54 AM 5/27/00 +0200, John Hay wrote:
> > >> In message <[EMAIL PROTECTED]> Dennis writes:
> > >> : My 4.0 system doesnt probe ISA devices on my system.
> > >> :
> > >> : Whats the trick? Is there a config requirement with old-styl
On Sat, 27 May 2000, Warner Losh wrote:
[ ... ]
> : I donnot have NetBSD. If you can give me some pointers to relevant files
> : that address the bus interface, I will try to download them and look into.
> : I am only interested in the specification, so header files should be
> : enough, unles
> Existing bus abstractions tend to let think that the same software driver
> can deal with different buses, bridges or IO methods without having to
> care about how these things actually behave, notably regarding buffering
> and ordering rules. This is untrue.
A good bus abstraction lets you car
In message <[EMAIL PROTECTED]>
=?ISO-8859-1?Q?G=E9rard_Roudier?= writes:
: It seems that some MIPS machines only flush bridge buffering when a
: interrupt is raised. I didn't remember where I read that. For those ones,
: the only way to have workable drivers is to let the device stall until the
:
On Sat, 27 May 2000, Warner Losh wrote:
> In message <[EMAIL PROTECTED]>
>=?ISO-8859-1?Q?G=E9rard_Roudier?= writes:
> : Existing bus abstractions tend to let think that the same software driver
> : can deal with different buses, bridges or IO methods without having to
> : care about how these
In message <[EMAIL PROTECTED]>
=?ISO-8859-1?Q?G=E9rard_Roudier?= writes:
: Existing bus abstractions tend to let think that the same software driver
: can deal with different buses, bridges or IO methods without having to
: care about how these things actually behave, notably regarding buffering
> YesWhose brainstorm was it to use the new convoluted bus nonsense in
> FreeBSD 4.0? Clearly someone who never wrote a driver with a complex
> controller with indexed memory mapped registers.Whats next, assembler drivers
If you cannot conduct yourself in a professional manner in these
mailin
On Sat, 27 May 2000, Jeroen Ruigrok van der Werven wrote:
> -On [2527 21:06], Dennis ([EMAIL PROTECTED]) wrote:
> >
> >Its seems rather humorous that the "generic" bus implementation requires
> >that isa drivers be hacked into the kernel with a build-time include. Very
> >humorous indeed. I
-On [2527 21:06], Dennis ([EMAIL PROTECTED]) wrote:
>
>Its seems rather humorous that the "generic" bus implementation requires
>that isa drivers be hacked into the kernel with a build-time include. Very
>humorous indeed. Is this a temporary condition as was the deboggle in v3.0?
Yeah I laugh
On Sat, May 27, 2000 at 03:51:24PM -0400, [EMAIL PROTECTED] wrote:
> YesWhose brainstorm was it to use the new convoluted bus nonsense in
> FreeBSD 4.0? Clearly someone who never wrote a driver with a complex
> controller with indexed memory mapped registers.Whats next, assembler drivers?
[..
On Sat, 27 May 2000, Dennis wrote:
> At 09:54 AM 5/27/00 +0200, John Hay wrote:
> >> In message <[EMAIL PROTECTED]> Dennis writes:
> >> : My 4.0 system doesnt probe ISA devices on my system.
> >> :
> >> : Whats the trick? Is there a config requirement with old-style drivers?
> >>
> >> They pro
> At 09:54 AM 5/27/00 +0200, John Hay wrote:
> >> In message <[EMAIL PROTECTED]> Dennis writes:
> >> : My 4.0 system doesnt probe ISA devices on my system.
> >> :
> >> : Whats the trick? Is there a config requirement with old-style drivers?
> >>
> >> They probe great for me. what, specifically
At 09:54 AM 5/27/00 +0200, John Hay wrote:
>> In message <[EMAIL PROTECTED]> Dennis writes:
>> : My 4.0 system doesnt probe ISA devices on my system.
>> :
>> : Whats the trick? Is there a config requirement with old-style drivers?
>>
>> They probe great for me. what, specifically, isn't probin
> In message <[EMAIL PROTECTED]> Dennis writes:
> : My 4.0 system doesnt probe ISA devices on my system.
> :
> : Whats the trick? Is there a config requirement with old-style drivers?
>
> They probe great for me. what, specifically, isn't probing?
He is probably talking about their own driver
In message <[EMAIL PROTECTED]> Dennis writes:
: My 4.0 system doesnt probe ISA devices on my system.
:
: Whats the trick? Is there a config requirement with old-style drivers?
They probe great for me. what, specifically, isn't probing?
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
w
My 4.0 system doesnt probe ISA devices on my system.
Whats the trick? Is there a config requirement with old-style drivers?
Dennis
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
33 matches
Mail list logo
