Mailing List Archive: Linux: Kernel

[GIT PATCH] more Driver core patches for 2.6.19

1 2 3

View All

Index | Next | Previous | View Threaded

torvalds at osdl

Dec 14, 2006, 9:22 AM

Post #51 of 68 (5977 views)
Permalink

Re: [GIT PATCH] more Driver core patches for 2.6.19 [In reply to]

On Wed, 13 Dec 2006, Alan wrote:
>
> He only owns a small amount of the code. Furthermore he imported third
> party GPL code using the license as sole permission. So he may have dug
> a personal hole but many of the rest of us have been repeatedly saying
> whenever he said that - that we do not agree.

[ The "he" being me in the above ]

Btw, I'd like to make it clear in this discussion too (as I have in
others), that I agree 100% with Alan here.

The thing is, my opinion is really just _my_ opinion. People shouldn't see
it as anything else. When I say "I don't think we should totally disallow
binary modules", you should always keep in mind that:

- the fact that I think that _some_ binary modules may be perfectly legal
does not mean that I think _all_ binary modules would be legal. I think
there are lots of ways to make such a binary module that is obviously
not ok.

- I really _am_ just one of hundreds of copyright owners. The fact that
_I_ am not necessarily all that eager to take things to court should in
no way be seen as estoppel for _others_ who decide that they want to
flex their legal rights.

So when I "may have dug a personal hole", please realize that this is
actually a personal - and conscious - choice. I've never wanted to do
copyright assignments, for several reasons: I think they are nasty and
wrong personally, and I'd hate all the paperwork, and I think it would
actually detract from the development model.

But one of the reasons I've never wanted copyright assignments is that I'm
personally actually _more_ comfortable with the system being co-owned. I
_like_ having my hands bound, and being in that hole. Not because of any
strange sexual hangups either, but simply because I think being personally
limited is something that makes people trust me more in the end - or
rather, it is something that means that people don't _have_ to trust me.

So people know that I can't unilaterally change the license. And they
_know_ that they can actually take things to court on their own. AND THAT
IS A GOOD THING. The last thing anybody _ever_ wants is to have me having
absolute powers. Not you guys, and certainly not me.

So you guys should always be happy, realizing that Linus may have his
quirks, but that my quirks can't ever really screw you guys up.

So I repeat: my opinions are _my_ opinions. Nobody else is legally bound
by them. And I'm certainly willing to bend my behaviour in the presense of
pressure (I think only mindless idiots can't change their mind - I
personally change some of my opinions several times a day just to keep
them fresh), but in somethign like this, where I _do_ have a fairly strong
opinion, I really think that this kind of patch has to be merged in
somebody elses tree than mine.

If, after a year, it turns out that my tree is the only one that doesn't
have that clause, I think I'll either get the hint, or people will realize
that I'm pointless and will just ignore me. It will have taken you long
enough to realize that ;)

Because one of the great things about the GPL is that _nobody_ has the
power to deny other peoples will. Not even me, not even for the kernel.

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

torvalds at osdl

Dec 14, 2006, 9:26 AM

Post #52 of 68 (5963 views)
Permalink

Re: [GIT PATCH] more Driver core patches for 2.6.19 [In reply to]

On Thu, 14 Dec 2006, Jan Engelhardt wrote:
>
> I don't get you. The rtc module does something similar (RTC generates
> interrupts and notifies userspace about it)

The RTC module knows how to shut the interrupt up.

(And in many cases, timers are special. Timers, by design, are often "edge
triggered" even in systems that have no other interrupts that work that
way. Exactly because a timer is special. So the RTC module often knows
that it doesn't need to do anything at all to shut it up, but even that
is special per-device knowledge, that is NOT TRUE for any normal devices).

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

torvalds at osdl

Dec 14, 2006, 9:32 AM

Post #53 of 68 (6064 views)
Permalink

Re: [GIT PATCH] more Driver core patches for 2.6.19 [In reply to]

On Thu, 14 Dec 2006, Jan Engelhardt wrote:
>
> Rather than IRQ_HANDLED, it should have been: remove this irq handler
> from the irq handlers for irq number N, so that it does not get called
> again until userspace has acked it.

Wrongo.

That just means that the _handler_ won't be called.

But the irq still stays active, and if it's shared, ALL THE OTHER HANDLERS
FOR THAT INTERRUPT will be called.

Over and over again. Forever. Because the machine won't be making any
progress, and the user-level code (which might know how to shut it up)
won't ever be called, because the machine is busy just doing interrupt
delivery all the time.

> See, maybe I don't have enough clue yet to exactly figure out why you
> say it does not work. However, this is how simple people see it 8)

You may be a bit simple. But I think it's more polite to call you
"special". Or maybe just not very used to how hardware works.

Btw, this is not something theoretical. We used to have this particular
problem _all_ the time with PCMCIA back when we weren't as good at
interrupt routing. You'd insert a PCMCIA card, and the machine just hung.
Hard.

And the reason was that it would send an irq, but we were expecting it on
another interrupt. But if it showed up on something that was shared, you'd
have a hung machine, because you'd just have the (say) ethernet driver
saying "not for me", and returning. And obviously not able to actually
shut it up, so when we returned from the interrupt handler, the interrupt
happened immediately again.

So this really isn't theoretical. It's a very common failure schenario for
mishandled interrupts. In fact, exactly because it's so common, these days
we have all this special logic in the generic interrupt layer that
notices, and shuts them up entirely (but does so by disabling _all_ the
devices on that interrupt, so when this happens, you might well lose your
disk driver or somethign else).

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

bernd at firmix

Dec 14, 2006, 9:34 AM

Post #54 of 68 (5981 views)
Permalink

Re: [GIT PATCH] more Driver core patches for 2.6.19 [In reply to]

On Thu, 2006-12-14 at 10:56 +0100, Hans-Jürgen Koch wrote:
[....]
> A small German manufacturer produces high-end AD converter cards. He sells
> 100 pieces per year, only in Germany and only with Windows drivers. He would
> now like to make his cards work with Linux. He has two driver programmers
> with little experience in writing Linux kernel drivers. What do you tell him?
> Write a large kernel module from scratch? Completely rewrite his code
> because it uses floating point arithmetics?

Find a Linux kernel guru/company and pay him/them for
-) an evaluation if it is "better" (for whatever better means) to port
the driver
or write it from scratch and
-) do the better thing.

Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

hjk at linutronix

Dec 14, 2006, 9:47 AM

Post #55 of 68 (5990 views)
Permalink

Re: [GIT PATCH] more Driver core patches for 2.6.19 [In reply to]

Am Donnerstag, 14. Dezember 2006 18:34 schrieb Bernd Petrovitsch:
> On Thu, 2006-12-14 at 10:56 +0100, Hans-Jürgen Koch wrote:
> [....]
> > A small German manufacturer produces high-end AD converter cards. He sells
> > 100 pieces per year, only in Germany and only with Windows drivers. He would
> > now like to make his cards work with Linux. He has two driver programmers
> > with little experience in writing Linux kernel drivers. What do you tell him?
> > Write a large kernel module from scratch? Completely rewrite his code
> > because it uses floating point arithmetics?
>
> Find a Linux kernel guru/company and pay him/them for
> -) an evaluation if it is "better" (for whatever better means) to port
> the driver
> or write it from scratch and
> -) do the better thing.

Good idea - whatever "porting" means. There are lots of Windows drivers out there
that are also partly user space using that Kithara stuff. They have most of their
driver in a dll. So that is similar to what we want with UIO - except that we
handle interrupts in a clean way, they don't.
If you need to port such a driver, simply writing a kernel module and a user space
library would change so much of the concept that you can start rewriting it from
scratch. And you'll have a large kernel module to maintain. OK, the guru/company
can earn money with it, at least as long as the customer doesn't realize it is
not the best solution for him.

Hans

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

jengelh at linux01

Dec 14, 2006, 9:57 AM

Post #56 of 68 (5979 views)
Permalink

Re: [GIT PATCH] more Driver core patches for 2.6.19 [In reply to]

On Dec 14 2006 18:17, Hans-Jürgen Koch wrote:
>>
>> They use floating point in (Windows) kernelspace? Oh my.
>
>To be honest, I never really understood where kernel space starts and user space
>ends in Windows, so I'm not sure about this :-)

Well, in Windows 95/98 you could do inportb (inb) and friends from "userspace"
without an extra kernel driver. Maybe it just always ran in kernelspace,
explains why many say 95/98 was less stable than the NT-based versions.

-`J'
--

bernd at firmix

Dec 14, 2006, 9:59 AM

Post #57 of 68 (5991 views)
Permalink

Re: [GIT PATCH] more Driver core patches for 2.6.19 [In reply to]

On Thu, 2006-12-14 at 18:47 +0100, Hans-Jürgen Koch wrote:
> Am Donnerstag, 14. Dezember 2006 18:34 schrieb Bernd Petrovitsch:
> > On Thu, 2006-12-14 at 10:56 +0100, Hans-Jürgen Koch wrote:
> > [....]
> > > A small German manufacturer produces high-end AD converter cards. He sells
> > > 100 pieces per year, only in Germany and only with Windows drivers. He would
> > > now like to make his cards work with Linux. He has two driver programmers
> > > with little experience in writing Linux kernel drivers. What do you tell him?
> > > Write a large kernel module from scratch? Completely rewrite his code
> > > because it uses floating point arithmetics?
> >
> > Find a Linux kernel guru/company and pay him/them for
> > -) an evaluation if it is "better" (for whatever better means) to port
> > the driver
> > or write it from scratch and
> > -) do the better thing.
>
> Good idea - whatever "porting" means. There are lots of Windows drivers out there

Yes, I didn't want to open that can of worms.

> that are also partly user space using that Kithara stuff. They have most of their
> driver in a dll. So that is similar to what we want with UIO - except that we
> handle interrupts in a clean way, they don't.
> If you need to port such a driver, simply writing a kernel module and a user space
> library would change so much of the concept that you can start rewriting it from

Of course, if "better" means "as cheap as possible no matter what", this
is probably the way to go.
Tough luck if you get into technical problems .....

> scratch. And you'll have a large kernel module to maintain. OK, the guru/company
> can earn money with it, at least as long as the customer doesn't realize it is
> not the best solution for him.

Depending on the definition of "best".

Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

jengelh at linux01

Dec 14, 2006, 10:04 AM

Post #58 of 68 (5972 views)
Permalink

Re: [GIT PATCH] more Driver core patches for 2.6.19 [In reply to]

On Dec 14 2006 09:32, Linus Torvalds wrote:
>On Thu, 14 Dec 2006, Jan Engelhardt wrote:
>>
>> Rather than IRQ_HANDLED, it should have been: remove this irq
>> handler from the irq handlers for irq number N, so that it does
>> not get called again until userspace has acked it.
>
>That just means that the _handler_ won't be called. But the irq
>still stays active, and if it's shared, ALL THE OTHER HANDLERS FOR
>THAT INTERRUPT will be called.
>[...]
>And the reason was that it would send an irq, but we were expecting
>it on another interrupt. But if it showed up on something that was
>shared, you'd have a hung machine, because you'd just have the (say)
>ethernet driver saying "not for me", and returning. And obviously
>not able to actually shut it up, so when we returned from the
>interrupt handler, the interrupt happened immediately again.

Thanks for this explanation, I see the point. Removing the uio irq
handler will leave the irq chain only with "not for me" devices. In
that case, would it make sense to install a replacement uio handler
that says "yes, that's mine" [.but ignoring it since userspace has not
yet finished with it]? (I think I've gotten into a loop since that
would be the IRQ_HANDLED case.) Mh, delicate problem.

-`J'
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

galibert at pobox

Dec 14, 2006, 11:16 AM

Post #59 of 68 (5972 views)
Permalink

Re: [GIT PATCH] more Driver core patches for 2.6.19 [In reply to]

On Thu, Dec 14, 2006 at 01:45:16PM +0100, Hans-J�rgen Koch wrote:
> What you suggest is not a "small kernel module". It's what we have now,
> writing a complete driver.

Who says a complete driver has to be big?

> That's what UIO does, plus some standard sysfs files, that tell you e.g.
> the size of the cards memory you can map. There are standard file names
> that allow you e.g. to automatically search for all registered uio
> drivers and their properties.

Which makes the userspace code much more complex than needed.

> If the card already has that data in its dual port RAM, you do an
> unneccessary copy.

Unnecessary only if
[card data rate]*[maximum userspace latency] < [dual port ram size].

Doing the buffering in the kernel where it belongs changes the right
part of the equation to [buffer size], which can be orders of
magnitude way bigger. And you can have the card DMA into the buffer
directly if you feel like it.

> > - implements a read interface to read data from the buffer
>
> Here you do the next unneccessary copy.

You can mmap, you can splice(), none is really hard.

> > - implement ioctls for whatever controls you need
>
> Implementing ioctls for everything is bad coding style and a has bad
> performance.

I thought the ALSA guys always said their stuff was high performance?

In any case, if ioctl is too slow for your controls, it means that
your ioctls are too low level, as in register access instead of
"reboot card at address x". And uio, with its lack of protection
against wandering interrupts, can't cut it.

> I said "high-end AD card", that means you have a
> signal processor on that board, want to download firmware to it
> and so on. You end up copying lots of data between user space
> and kernel space.

You're allowed to implement write() too.

> Yes, that's a complete kernel driver that you'd never get into
> a mainline kernel. Furthermore, the card manufacturer would have to
> employ at least two experienced Linux _kernel_ programmers. That's
> too much for a small company who's business is something different.

So they have a choice between learning a minimum of linux kernel
internals, or a minimum of uio. I suspect the hidden kinks of uio and
relative lack of documentation make the kernel route *way* easier.

> You can achieve 100 lines with uio, including sysfs and poll. What you
> describe would never fit in 200 lines for a non-trivial card.

Ok, 200 is an exaggeration. Here is a 600-lines 2.4 driver that does
what I say, with direct dma to the internal buffer from the card and
userland-driven firmware upload. I know that a 2.6 version would
actually be smaller.

OG.

Attachments:

iiadc64.c (14.3 KB)

iiadc64.h (1.44 KB)

tglx at linutronix

Dec 14, 2006, 12:47 PM

Post #60 of 68 (5960 views)
Permalink

Re: [GIT PATCH] more Driver core patches for 2.6.19 [In reply to]

On Thu, 2006-12-14 at 09:26 -0800, Linus Torvalds wrote:
>
> On Thu, 14 Dec 2006, Jan Engelhardt wrote:
> >
> > I don't get you. The rtc module does something similar (RTC generates
> > interrupts and notifies userspace about it)
>
> The RTC module knows how to shut the interrupt up.

The kernel part of the UIO driver also knows how to shut the interrupt
up, so where is the difference ?

tglx

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

torvalds at osdl

Dec 14, 2006, 2:59 PM

Post #61 of 68 (5979 views)
Permalink

Re: [GIT PATCH] more Driver core patches for 2.6.19 [In reply to]

On Thu, 14 Dec 2006, Thomas Gleixner wrote:
>
> The kernel part of the UIO driver also knows how to shut the interrupt
> up, so where is the difference ?

Thomas, you've been discussing some totally different and private
Thomas-only thread than everybody else in this thread has been.

The point is NO, THE UIO DRIVER DID NOT KNOW THAT AT ALL. Go and read the
post that STARTED this whole thread. Go and read the "example driver".

The example driver was complete crap and drivel.

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

tglx at linutronix

Dec 14, 2006, 3:37 PM

Post #62 of 68 (5989 views)
Permalink

Re: [GIT PATCH] more Driver core patches for 2.6.19 [In reply to]

Linus,

On Thu, 2006-12-14 at 14:59 -0800, Linus Torvalds wrote:
> > The kernel part of the UIO driver also knows how to shut the interrupt
> > up, so where is the difference ?
>
> Thomas, you've been discussing some totally different and private
> Thomas-only thread than everybody else in this thread has been.

Yeah, I even looked at different code than others, until they noticed
that email before coffee is bad. :)

> The point is NO, THE UIO DRIVER DID NOT KNOW THAT AT ALL. Go and read the
> post that STARTED this whole thread. Go and read the "example driver".
>
> The example driver was complete crap and drivel.

Sigh, I accept and also Greg has done this before, that the example
driver based on the LPT port was not a fortunate choice. It was done to
provide some example which is reproducible on COTS hardware.

Real world drivers like the sercos example I provided - and I do it
again - are aware of that problem:

/*
* The chip specific portion of the interrupt handler. The framework code
* takes care of userspace notification when we return IRQ_HANDLED
*/
static irqreturn_t sercos_handler(int irq, void *dev_id, struct pt_regs *reg)
{
/* Check, if this interrupt is originated from the SERCOS chip */
if (!(sercos_read(IRQ_STATUS) & SERCOS_INTERRUPT_MASK))
return IRQ_NONE;

---------^ Makes it safe for IRQ sharing

/* Acknowledge the chip interrupts */
sercos_write(IRQ_ACK1, SERCOS_INTERRUPT_ACK1);
sercos_write(IRQ_ACK2, SERCOS_INTERRUPT_ACK2);

----------^
Actually prevents the box is dead scenario, as it disables the
interrupt from that device until it is reenabled from the user space
driver code. This covers also the case where the user space driver dies,
as the kernel still has the portion of code to shut this thing up for
ever.
return IRQ_HANDLED;
}

The concept requires, that
- the interrupt handling is in the kernel _AND_ open source
- the mapping of the device is done via the kernel controlled mapping
function rather than by poking in the PCI regs

I really regret that I ever came up with this LPT example, but cutting
the whole discussion down to that ugly example driver does not get us
anywhere.

tglx

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

pavel at suse

Dec 16, 2006, 1:05 AM

Post #63 of 68 (5898 views)
Permalink

Re: [GIT PATCH] more Driver core patches for 2.6.19 [In reply to]

Hi!

> > Seriously, though, please please pretty please do not allow a facility
> > for "going through a simple interface to get accesses to irqs and
> > memory regions" into the mainline kernel, with or without toy ISA
> > examples.
>
> I do agree.
>
> I'm not violently opposed to something like this in practice (we've
> already allowed it for USB devices), but there definitely needs to be a
> real reason that helps _us_, not just some ass-hat vendor that looks for a
> way to avoid open-sourcing their driver.
>
> If there are real and valid uses (and as mentioned, I actually think that
> the whole graphics-3D-engine-thing is such a use) where a kernel driver
> simply doesn't work out well, or where there are serious tecnical reasons
> why it wants to be in user space (and "stability" is not one such thing:
> if you access hardware directly in user space, and your driver is buggy,
> the machine is equally deal, and a hell of a lot harder to control to
> boot).

Well.. it is easier to debug in userspace. While bad hw access can
still kill the box, bad free() will not, and most bugs in early
developent are actually of 2nd kind.
Pavel
--
Thanks for all the (sleeping) penguins.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

pavel at suse

Dec 16, 2006, 1:05 AM

Post #64 of 68 (5935 views)
Permalink

Re: [GIT PATCH] more Driver core patches for 2.6.19 [In reply to]

joern at lazybastard

Dec 16, 2006, 3:04 AM

Post #65 of 68 (5945 views)
Permalink

Re: [GIT PATCH] more Driver core patches for 2.6.19 [In reply to]

On Sat, 16 December 2006 09:05:32 +0000, Pavel Machek wrote:
>
> Well.. it is easier to debug in userspace. While bad hw access can
> still kill the box, bad free() will not, and most bugs in early
> developent are actually of 2nd kind.

Isn't that what qemu is for?

Jörn

--
Happiness isn't having what you want, it's wanting what you have.
-- unknown
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

rlrevell at joe-job

Dec 16, 2006, 12:13 PM

Post #66 of 68 (5917 views)
Permalink

Re: [GIT PATCH] more Driver core patches for 2.6.19 [In reply to]

On Thu, 2006-12-14 at 18:02 +0100, Jan Engelhardt wrote:
> On Dec 14 2006 10:56, Hans-J�rgen Koch wrote:
> >
> >A small German manufacturer produces high-end AD converter cards. He sells
> >100 pieces per year, only in Germany and only with Windows drivers. He would
> >now like to make his cards work with Linux. He has two driver programmers
> >with little experience in writing Linux kernel drivers. What do you tell him?
> >Write a large kernel module from scratch? Completely rewrite his code
> >because it uses floating point arithmetics?
>
> They use floating point in (Windows) kernelspace? Oh my.

Yes, definitely. For example lots of Windows sound drivers do AC3
decoding in kernelspace. Of course the vendors usually lie and say it's
done in hardware...

Lee

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

jengelh at linux01

Dec 16, 2006, 12:28 PM

Post #67 of 68 (5938 views)
Permalink

Re: [GIT PATCH] more Driver core patches for 2.6.19 [In reply to]

On Dec 16 2006 15:13, Lee Revell wrote:
>On Thu, 2006-12-14 at 18:02 +0100, Jan Engelhardt wrote:
>>
>> They use floating point in (Windows) kernelspace? Oh my.
>
>Yes, definitely.

Explains why Windows is so slow ;-) [FPU restore and stuff...]

On that matter, when does the Linux kernel do proper FPU handling? At context
switches? If so, would not that make a kthread fpu-capable?

>For example lots of Windows sound drivers do AC3 decoding in kernelspace.
>Of course the vendors usually lie and say it's done in hardware...

They don't need to lie, the user buys it anyway...

-`J'
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

pavel at ucw

Dec 17, 2006, 2:49 AM

Post #68 of 68 (5918 views)
Permalink

Re: [GIT PATCH] more Driver core patches for 2.6.19 [In reply to]

Hi!

> > Well.. it is easier to debug in userspace. While bad hw access can
> > still kill the box, bad free() will not, and most bugs in early
> > developent are actually of 2nd kind.
>
> Isn't that what qemu is for?

I do not think you can reasonably debug driver for new hardware under
qemu.

Anyway, doing it in userspace is just convenient.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

1 2 3

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads