Re: [RFC] BadRAM still not ready for inclusion ? (was: Re: Free Linux Driver Development!)

[Pavel Machek]

Hi!

> >What's so hard about submitting a 200 line patch to LKML?
> 
> that's what i was wondering about ;D
> it's not the first time, that i see nice features not being submitted to lkml.
> 
> anyway - pavel (thanks btw!) just pointed me to some param "mem=exactmap" :
> 
> >I think functionality is there in latest vanila with mem=exactmap even
> >w/o patches.
> 
> so, maybe we need to find out _if_ and _how_ this could make BadRAM obsolete 
> (i.e. if this is a good alternative) ?
> (so we won't need to discuss about BadRAM inclusion anymore. :)
> 
> what i found is:
> 
> 894 memmap=exactmap [KNL,IA-32,X86_64] Enable setting of an exact
> 895 E820 memory map, as specified by the user.
> 896 Such memmap=exactmap lines can be constructed 
> based on
> 897 BIOS output or other requirements. See the [EMAIL 
> PROTECTED]
> 898 option description.
> 899 
> 900 [EMAIL PROTECTED]
> 901 [KNL] Force usage of a specific region of memory
> 902 Region of memory to be used, from ss to ss+nn.
> 903 
> 904 memmap=nn[KMG]#ss[KMG]
> 905 [KNL,ACPI] Mark specific memory as ACPI data.
> 906 Region of memory to be used, from ss to ss+nn.
> 907 
> 908 memmap=nn[KMG]$ss[KMG]
> 909 [KNL,ACPI] Mark specific memory as reserved.
> 910 Region of memory to be used, from ss to ss+nn.

>  this indeed looks like something being able to replace BadRAM, but
> the question is, how to handle/enable that and how to translate
> BadRAM patterns from memtest86 to be usable. (i.e.: writing a HowTo
> for the average user not being a kernel wizard) 

Writing a howto, or maybe writting a shellscript to do a translation
:-). It will not be trivial, but certainly better than trying to push
the badram patch. Good luck ;-).

(e820 map is available from dmesg after boot, and perhaps from other
places. First, you'll need to duplicate it on cmdline using
memmap=... arguments. Then, if bad ram is in the middle of something,
you'll need to split memmap= accordingly).
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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] BadRAM still not ready for inclusion ? (was: Re: Free Linux Driver Development!)

[Pavel Machek]

Hi!

 What's so hard about submitting a 200 line patch to LKML?
 
 that's what i was wondering about ;D
 it's not the first time, that i see nice features not being submitted to lkml.
 
 anyway - pavel (thanks btw!) just pointed me to some param mem=exactmap :
 
 I think functionality is there in latest vanila with mem=exactmap even
 w/o patches.
 
 so, maybe we need to find out _if_ and _how_ this could make BadRAM obsolete 
 (i.e. if this is a good alternative) ?
 (so we won't need to discuss about BadRAM inclusion anymore. :)
 
 what i found is:
 
 894 memmap=exactmap [KNL,IA-32,X86_64] Enable setting of an exact
 895 E820 memory map, as specified by the user.
 896 Such memmap=exactmap lines can be constructed 
 based on
 897 BIOS output or other requirements. See the [EMAIL 
 PROTECTED]
 898 option description.
 899 
 900 [EMAIL PROTECTED]
 901 [KNL] Force usage of a specific region of memory
 902 Region of memory to be used, from ss to ss+nn.
 903 
 904 memmap=nn[KMG]#ss[KMG]
 905 [KNL,ACPI] Mark specific memory as ACPI data.
 906 Region of memory to be used, from ss to ss+nn.
 907 
 908 memmap=nn[KMG]$ss[KMG]
 909 [KNL,ACPI] Mark specific memory as reserved.
 910 Region of memory to be used, from ss to ss+nn.

  this indeed looks like something being able to replace BadRAM, but
 the question is, how to handle/enable that and how to translate
 BadRAM patterns from memtest86 to be usable. (i.e.: writing a HowTo
 for the average user not being a kernel wizard) 

Writing a howto, or maybe writting a shellscript to do a translation
:-). It will not be trivial, but certainly better than trying to push
the badram patch. Good luck ;-).

(e820 map is available from dmesg after boot, and perhaps from other
places. First, you'll need to duplicate it on cmdline using
memmap=... arguments. Then, if bad ram is in the middle of something,
you'll need to split memmap= accordingly).
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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] BadRAM still not ready for inclusion ? (was: Re: Free Linux Driver Development!)

[Lee Revell]

On 3/4/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

It seems, that BadRAM is not being maintained very actively and the original author 
doesn`t seem to have the time pushing it into mainline, but i know it's actively being 
used by more then just a handful of people. Unfortunately there is no mailinglist to 
approve this and some "central point of communication" besides Rick van Rein 
doesn't seem to exist. There is a fork named BadMEM at 
http://sourceforge.net/projects/badmem, Memtest86 also supporting BadRAM and i have seen 
LOTs of discussion about BadRAM on the net. Most of that discussion was due to problems 
getting it run with Kernel XYZ.

Basically, this feature is a matter of adding/modifying 200 lines of code, so 
iŽm even more wondering, why it exists for more than 7 years and nothing 
happening here.


Because most kernel developers don't have time to scour the net for
random kernel patches and pull them.  If you have a useful patch you
want merged it's up to you to push it.

What's so hard about submitting a 200 line patch to LKML?

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

Re: [RFC] BadRAM still not ready for inclusion ? (was: Re: Free Linux Driver Development!)

[Bill Davidsen]

telling [EMAIL PROTECTED] wrote:

Hello !

There's some really nice feature-patch named BadRAM at

http://rick.vanrein.org/linux/badram/index.html for years now, being
announced around 2000 on this list, voted for inclusion in 2.3.99.


BadRAM let's you tell the kernel to skip certain regions of ram, so

you can continue using defective modules. Some older article describing
BadRAM in more detail is at http://www.linuxjournal.com/article/4489

[...snip...]


Basically, this feature is a matter of adding/modifying 200 lines of

code, so iŽm even more wondering, why it exists for more than 7 years
and nothing happening here. I don`t know of any kernel patch which is
comparable to this.


Think about that... 200 lines of code which will have to be maintained 
forever, once it becomes a supported feature, for the benefit of the few 
people who can't or won't replace bad memory.



This patch is real a ressource-saver - if being a standard Linux

feature, it will save even more ressources: Saving user's time (because
they are pulling their hair out to get this run with kernel XYZ) and
also saving CPU time (no compile orgies anymore), and thus waste of energy.


Consider one technical and one human behavour issue. While memory with 
"bad spots" was common a decade ago, it's as likely with current memory 
that the memory will "throw a bad bit" once in a while, on a read or 
write anywhere in the marginal or bad chip. Depending on how the memory 
is organized that could be 1/16th of the memory as a block of 32MB on a 
512MB part, or every 16th byte in the whole memory.


As for the human issue, how many more people will use this capability to 
avoid buying memory, run with only part of the bad memory detected and 
blocked out, get unreliable operation, and think that Linux is unreliable.



Please comment if someone sees chances of getting this (after years
of

existance) into mainline and also please jump in to make the good thing
happen !


I personally think that the patch is at best a balance between benefit 
and problems. As a patch I have to use deliberately I think it's a good 
idea. As a permanent and default part of the kernel, I'm not convinced. 
There are some patches I would love to see in mainline, like suspend2 
which includes resume as well as suspend, but this is not one of them, 
hope I've explained why.


As with so many other things in life, "it's not the cost but the upkeep."


Historical patch collection at:
http://rick.vanrein.org/linux/badram/download.html

Most recent version of BadRAM should be:
http://rick.vanrein.org/linux/badram/software/BadRAM-2.6.19.1.patch

Sorry for being a little bit "noisy" here, but I think BadRAM is a

great feature and Linux could really benefit from that.


regards
Roland K.
Sysadmin


List:   linux-kernel
Subject:Re: Free Linux Driver Development!
From:   devzero () web ! de
Date:   2007-02-04 21:37:33
Message-ID: 1605445807 () web ! de
[Download message RAW]

First off, compliments to this announcement, I liked it very much!

Some comment regarding those "volunteers, waiting to get some real work" :)


OK, but why isn't your army of volunteers fixing them?



They don't know about them, or they don't have the hardware to test?
Seriously, let the kernel-janitor's project know about any issues you
have and they will be glad to jump on it.  Those people are just
chomping a the bit to do something a bit bigger than "compiler warning
cleanups" :)


So many times i have seen good ideas brought up, kernel patches being written, 
posted \
to lkml, being developed outside mainline for a while and then being forgotten 
some \
time later due to lack of energy of some individual to get this into mainline.

If there is an noticeably number of talented programmers (unfortunately, i`m 
not) , \
so why not "feeding" them the right way ? Where is those public and transparent 
and \
moderated Linux-Kernel "ToDo"- or "Keep an eye on"-list, sorted by priorities, 
with \
sort of a "vote for this feature"-button, so those guys have something they can 
pick \
up? There is so much great stuff and ideas out there where they could put their 
work \
onto or getting involved, it just needs to be found or sort of being "managed" 
a \
little bit better.

For myself, i`m waiting for so quite some things to get "one step further", but 
they \
are more or less tied to some single individuals, for which you just cannot 
send some \
"hey, what`s up with your project"-message every second day. The interest in 
many \
nice projects often is quite low and evolution quite slow, but not only because 
of \
the fact that they aren`t great, but more because of not getting widely known. 
It`s \
not always missing specs, it`s also some missing noise/feedback for different \
features or missing of some "driving force" to bring things

Re: [RFC] BadRAM still not ready for inclusion ? (was: Re: Free Linux Driver Development!)

[Bill Davidsen]

telling [EMAIL PROTECTED] wrote:

Hello !

There's some really nice feature-patch named BadRAM at

http://rick.vanrein.org/linux/badram/index.html for years now, being
announced around 2000 on this list, voted for inclusion in 2.3.99.


BadRAM let's you tell the kernel to skip certain regions of ram, so

you can continue using defective modules. Some older article describing
BadRAM in more detail is at http://www.linuxjournal.com/article/4489

[...snip...]


Basically, this feature is a matter of adding/modifying 200 lines of

code, so iŽm even more wondering, why it exists for more than 7 years
and nothing happening here. I don`t know of any kernel patch which is
comparable to this.


Think about that... 200 lines of code which will have to be maintained 
forever, once it becomes a supported feature, for the benefit of the few 
people who can't or won't replace bad memory.



This patch is real a ressource-saver - if being a standard Linux

feature, it will save even more ressources: Saving user's time (because
they are pulling their hair out to get this run with kernel XYZ) and
also saving CPU time (no compile orgies anymore), and thus waste of energy.


Consider one technical and one human behavour issue. While memory with 
bad spots was common a decade ago, it's as likely with current memory 
that the memory will throw a bad bit once in a while, on a read or 
write anywhere in the marginal or bad chip. Depending on how the memory 
is organized that could be 1/16th of the memory as a block of 32MB on a 
512MB part, or every 16th byte in the whole memory.


As for the human issue, how many more people will use this capability to 
avoid buying memory, run with only part of the bad memory detected and 
blocked out, get unreliable operation, and think that Linux is unreliable.



Please comment if someone sees chances of getting this (after years
of

existance) into mainline and also please jump in to make the good thing
happen !


I personally think that the patch is at best a balance between benefit 
and problems. As a patch I have to use deliberately I think it's a good 
idea. As a permanent and default part of the kernel, I'm not convinced. 
There are some patches I would love to see in mainline, like suspend2 
which includes resume as well as suspend, but this is not one of them, 
hope I've explained why.


As with so many other things in life, it's not the cost but the upkeep.


Historical patch collection at:
http://rick.vanrein.org/linux/badram/download.html

Most recent version of BadRAM should be:
http://rick.vanrein.org/linux/badram/software/BadRAM-2.6.19.1.patch

Sorry for being a little bit noisy here, but I think BadRAM is a

great feature and Linux could really benefit from that.


regards
Roland K.
Sysadmin


List:   linux-kernel
Subject:Re: Free Linux Driver Development!
From:   devzero () web ! de
Date:   2007-02-04 21:37:33
Message-ID: 1605445807 () web ! de
[Download message RAW]

First off, compliments to this announcement, I liked it very much!

Some comment regarding those volunteers, waiting to get some real work :)


OK, but why isn't your army of volunteers fixing them?



They don't know about them, or they don't have the hardware to test?
Seriously, let the kernel-janitor's project know about any issues you
have and they will be glad to jump on it.  Those people are just
chomping a the bit to do something a bit bigger than compiler warning
cleanups :)


So many times i have seen good ideas brought up, kernel patches being written, 
posted \
to lkml, being developed outside mainline for a while and then being forgotten 
some \
time later due to lack of energy of some individual to get this into mainline.

If there is an noticeably number of talented programmers (unfortunately, i`m 
not) , \
so why not feeding them the right way ? Where is those public and transparent 
and \
moderated Linux-Kernel ToDo- or Keep an eye on-list, sorted by priorities, 
with \
sort of a vote for this feature-button, so those guys have something they can 
pick \
up? There is so much great stuff and ideas out there where they could put their 
work \
onto or getting involved, it just needs to be found or sort of being managed 
a \
little bit better.

For myself, i`m waiting for so quite some things to get one step further, but 
they \
are more or less tied to some single individuals, for which you just cannot 
send some \
hey, what`s up with your project-message every second day. The interest in 
many \
nice projects often is quite low and evolution quite slow, but not only because 
of \
the fact that they aren`t great, but more because of not getting widely known. 
It`s \
not always missing specs, it`s also some missing noise/feedback for different \
features or missing of some driving force to bring things forward. How should 
one \
developer know that somebody needs a feature if those who could probably need 
it \
don`t request it? Maybe just because of the fact that they even

Re: [RFC] BadRAM still not ready for inclusion ? (was: Re: Free Linux Driver Development!)

[Lee Revell]

On 3/4/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:

It seems, that BadRAM is not being maintained very actively and the original author 
doesn`t seem to have the time pushing it into mainline, but i know it's actively being 
used by more then just a handful of people. Unfortunately there is no mailinglist to 
approve this and some central point of communication besides Rick van Rein 
doesn't seem to exist. There is a fork named BadMEM at 
http://sourceforge.net/projects/badmem, Memtest86 also supporting BadRAM and i have seen 
LOTs of discussion about BadRAM on the net. Most of that discussion was due to problems 
getting it run with Kernel XYZ.

Basically, this feature is a matter of adding/modifying 200 lines of code, so 
iŽm even more wondering, why it exists for more than 7 years and nothing 
happening here.


Because most kernel developers don't have time to scour the net for
random kernel patches and pull them.  If you have a useful patch you
want merged it's up to you to push it.

What's so hard about submitting a 200 line patch to LKML?

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

Re: [RFC] BadRAM still not ready for inclusion ? (was: Re: Free Linux Driver Development!)

[debian developer]

The feature is not supported most prolly cos of lack of volunteers
pushing it into mainline, or it might be deprecated(is it??).
You are right in pointing out tht this could really save some ppl lots
of trouble.
am ready to help. pls contact for further queries




On 3/5/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>  Hello !
>
> There's some really nice feature-patch named BadRAM at 
http://rick.vanrein.org/linux/badram/index.html for years now, being announced 
around 2000 on this list, voted for inclusion in  2.3.99.
>
> BadRAM let's you tell the kernel to skip certain regions of ram, so you can 
continue using defective modules. Some older article describing BadRAM in more 
detail is at  http://www.linuxjournal.com/article/4489
>
> Some may tell "better buy some new ram" , but think of scenarios where ram being 
soldered onboard, modules not being available anymore due to special format - or people not having the 
money to buy new modules. Furthermore, this is good stuff for propaganda "Linux even works on 
machines with broken ram - no other operating system can do that!"
>
> It seems, that BadRAM is not being maintained very actively and the original author 
doesn`t seem to have the time pushing it into mainline, but i know it's actively being used 
by more then just a handful of people. Unfortunately there is no mailinglist to approve this 
and some "central point of communication" besides Rick van Rein doesn't seem to 
exist. There is a fork named BadMEM at  http://sourceforge.net/projects/badmem, Memtest86 
also supporting BadRAM and i have seen LOTs of discussion about BadRAM on the net. Most of 
that discussion was due to problems getting it run with Kernel XYZ.
>
> Basically, this feature is a matter of adding/modifying 200 lines of code, so 
iŽm even more wondering, why it exists for more than 7 years and nothing happening 
here. I don`t know of any kernel patch which is comparable to this.
>
> This patch is real a ressource-saver - if being a standard Linux feature, it 
will save even more ressources: Saving user's time (because they are pulling their 
hair out to get this run with kernel XYZ) and also saving CPU time  (no compile 
orgies anymore), and thus waste of energy.
>
> Please comment if someone sees chances of getting this (after years of 
existance) into mainline and also please jump in to make the good thing happen !
>
> Historical patch collection at:
>  http://rick.vanrein.org/linux/badram/download.html
>
> Most recent version of BadRAM should be:
> http://rick.vanrein.org/linux/badram/software/BadRAM-2.6.19.1.patch
>
> Sorry for being a little bit "noisy" here, but I think BadRAM is a great 
feature and Linux could really benefit from that.
>
> regards
> Roland K.
> Sysadmin
>
>
> List:   linux-kernel
>  Subject:Re: Free Linux Driver Development!
> From:   devzero () web ! de
> Date:   2007-02-04 21:37:33
> Message-ID: 1605445807 () web ! de
> [Download message RAW]
>
> First off, compliments to this announcement, I liked it very much!
>
> Some comment regarding those "volunteers, waiting to get some real work" :)
>
> > > OK, but why isn't your army of volunteers fixing them?
>
> > They don't know about them, or they don't have the hardware to test?
> > Seriously, let the kernel-janitor's project know about any issues you
> > have and they will be glad to jump on it.  Those people are just
> > chomping a the bit to do something a bit bigger than "compiler warning
> > cleanups" :)
>
> So many times i have seen good ideas brought up, kernel patches being 
written, posted \
> to lkml, being developed outside mainline for a while and then being 
forgotten some \
> time later due to lack of energy of some individual to get this into mainline.
>
> If there is an noticeably number of talented programmers (unfortunately, i`m 
not) , \
> so why not "feeding" them the right way ? Where is those public and 
transparent and \
> moderated Linux-Kernel "ToDo"- or "Keep an eye on"-list, sorted by 
priorities, with \
> sort of a "vote for this feature"-button, so those guys have something they 
can pick \
> up? There is so much great stuff and ideas out there where they could put 
their work \
> onto or getting involved, it just needs to be found or sort of being 
"managed" a \
> little bit better.
>
> For myself, i`m waiting for so quite some things to get "one step further", 
but they \
> are more or less tied to some single individuals, for which you just cannot 
send some \
>  "hey, what`s up with your project"-message every second day. The interest in 
many \
> nice projects often is quite low and evolution quite slow, but 

Re: [RFC] BadRAM still not ready for inclusion ? (was: Re: Free Linux Driver Development!)

[debian developer]

The feature is not supported most prolly cos of lack of volunteers
pushing it into mainline, or it might be deprecated(is it??).
You are right in pointing out tht this could really save some ppl lots
of trouble.
am ready to help. pls contact for further queries




On 3/5/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
  Hello !

 There's some really nice feature-patch named BadRAM at 
http://rick.vanrein.org/linux/badram/index.html for years now, being announced 
around 2000 on this list, voted for inclusion in  2.3.99.

 BadRAM let's you tell the kernel to skip certain regions of ram, so you can 
continue using defective modules. Some older article describing BadRAM in more 
detail is at  http://www.linuxjournal.com/article/4489

 Some may tell better buy some new ram , but think of scenarios where ram being 
soldered onboard, modules not being available anymore due to special format - or people not having the 
money to buy new modules. Furthermore, this is good stuff for propaganda Linux even works on 
machines with broken ram - no other operating system can do that!

 It seems, that BadRAM is not being maintained very actively and the original author 
doesn`t seem to have the time pushing it into mainline, but i know it's actively being used 
by more then just a handful of people. Unfortunately there is no mailinglist to approve this 
and some central point of communication besides Rick van Rein doesn't seem to 
exist. There is a fork named BadMEM at  http://sourceforge.net/projects/badmem, Memtest86 
also supporting BadRAM and i have seen LOTs of discussion about BadRAM on the net. Most of 
that discussion was due to problems getting it run with Kernel XYZ.

 Basically, this feature is a matter of adding/modifying 200 lines of code, so 
iŽm even more wondering, why it exists for more than 7 years and nothing happening 
here. I don`t know of any kernel patch which is comparable to this.

 This patch is real a ressource-saver - if being a standard Linux feature, it 
will save even more ressources: Saving user's time (because they are pulling their 
hair out to get this run with kernel XYZ) and also saving CPU time  (no compile 
orgies anymore), and thus waste of energy.

 Please comment if someone sees chances of getting this (after years of 
existance) into mainline and also please jump in to make the good thing happen !

 Historical patch collection at:
  http://rick.vanrein.org/linux/badram/download.html

 Most recent version of BadRAM should be:
 http://rick.vanrein.org/linux/badram/software/BadRAM-2.6.19.1.patch

 Sorry for being a little bit noisy here, but I think BadRAM is a great 
feature and Linux could really benefit from that.

 regards
 Roland K.
 Sysadmin


 List:   linux-kernel
  Subject:Re: Free Linux Driver Development!
 From:   devzero () web ! de
 Date:   2007-02-04 21:37:33
 Message-ID: 1605445807 () web ! de
 [Download message RAW]

 First off, compliments to this announcement, I liked it very much!

 Some comment regarding those volunteers, waiting to get some real work :)

   OK, but why isn't your army of volunteers fixing them?

  They don't know about them, or they don't have the hardware to test?
  Seriously, let the kernel-janitor's project know about any issues you
  have and they will be glad to jump on it.  Those people are just
  chomping a the bit to do something a bit bigger than compiler warning
  cleanups :)

 So many times i have seen good ideas brought up, kernel patches being 
written, posted \
 to lkml, being developed outside mainline for a while and then being 
forgotten some \
 time later due to lack of energy of some individual to get this into mainline.

 If there is an noticeably number of talented programmers (unfortunately, i`m 
not) , \
 so why not feeding them the right way ? Where is those public and 
transparent and \
 moderated Linux-Kernel ToDo- or Keep an eye on-list, sorted by 
priorities, with \
 sort of a vote for this feature-button, so those guys have something they 
can pick \
 up? There is so much great stuff and ideas out there where they could put 
their work \
 onto or getting involved, it just needs to be found or sort of being 
managed a \
 little bit better.

 For myself, i`m waiting for so quite some things to get one step further, 
but they \
 are more or less tied to some single individuals, for which you just cannot 
send some \
  hey, what`s up with your project-message every second day. The interest in 
many \
 nice projects often is quite low and evolution quite slow, but not only 
because of \
 the fact that they aren`t great, but more because of not getting widely 
known. It`s \
 not always missing specs, it`s also some missing noise/feedback for different 
\
 features or missing of some driving force to bring things forward. How 
should one \
 developer know that somebody needs a feature if those who could probably need 
it \
 don`t request it? Maybe just because of the fact that they even imagine

Re: Free Linux Driver Development!

[Pavel Machek]

Hi!

> > This kind of offer has _always_ been there for out-of-tree GPL drivers.
> > I have contacted many different groups and driver authors over the years
> > to offer my help in trying to get their code into the mainline kernel.
> > 
> > Some take me up on the offer, others ignore it, and still others activly
> > refuse to do so, saying they want to stay out-of-the tree (lirc is one
> > of these examples...)
> 
> I think the point is that if we are offering free development effort
> to write a driver which goes into mainline, maybe we should provide
> more than "providing rules and guidelines" so that people can spend
> engineering $$$ to get the driver into mainline.   
> 
> More specifically, Dave said that it "seemed rude" to just take the
> driver and send updates, but maybe the best way of dealing with
> out-of-tree drivers like lirc is to treat the out-of-tree drivers as a
> kind of spec release, and just have someone in the community forcibly
> take the code, fix it up, and then get it merged.  Maybe it's being
> "rude", but so is not responding to requests to get it merged.

So can I treat Shem's code as a spec release, and merge it? :-).

[Okay, so your position is more reasonable than expected, good; but
signed-off process strongly discourages merging some code without
author's cooperation.]
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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Pavel Machek]

Hi!

  This kind of offer has _always_ been there for out-of-tree GPL drivers.
  I have contacted many different groups and driver authors over the years
  to offer my help in trying to get their code into the mainline kernel.
  
  Some take me up on the offer, others ignore it, and still others activly
  refuse to do so, saying they want to stay out-of-the tree (lirc is one
  of these examples...)
 
 I think the point is that if we are offering free development effort
 to write a driver which goes into mainline, maybe we should provide
 more than providing rules and guidelines so that people can spend
 engineering $$$ to get the driver into mainline.   
 
 More specifically, Dave said that it seemed rude to just take the
 driver and send updates, but maybe the best way of dealing with
 out-of-tree drivers like lirc is to treat the out-of-tree drivers as a
 kind of spec release, and just have someone in the community forcibly
 take the code, fix it up, and then get it merged.  Maybe it's being
 rude, but so is not responding to requests to get it merged.

So can I treat Shem's code as a spec release, and merge it? :-).

[Okay, so your position is more reasonable than expected, good; but
signed-off process strongly discourages merging some code without
author's cooperation.]
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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[David Lang]

On Tue, 6 Feb 2007, Akemi Yagi wrote:


On Tue, 06 Feb 2007 19:07:50 +0530, Sunil Naidu wrote:


On 2/5/07, Stefan Seyfried <[EMAIL PROTECTED]> wrote:

On Wed, Jan 31, 2007 at 03:14:31AM +0100, Adrian Bunk wrote:

On Tue, Jan 30, 2007 at 05:24:28PM -0800, Greg KH wrote:


Wrong. I abandoned all floppy drives some years ago. I'd actually vote
for removing the floppy driver from the kernel completely.


I don't think time has come for that yet, still millions of people do use
Floppy on Linux ;-)


So, I am not the only person on earth who still makes sure the floppy gets
included when building a new custom PC?


No, I've avoided useing vendors that don't offer it as an option.

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

Re: Free Linux Driver Development!

[Greg KH]

On Wed, Feb 07, 2007 at 08:12:05AM +0100, Miguel Ojeda wrote:
> 
> As I'm not an expert in any kind of device, so I would like to join
> for any device which its type has not been assigned to any person yet
> (wild card?). Also, I would code for small LCDs.

Thanks, I've added you to the list.

I'll be doing a public update soon as people are wondering what is going
on :)

thanks,

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

Re: Free Linux Driver Development!

[Greg KH]

On Wed, Feb 07, 2007 at 06:03:58AM -0800, Tejun Heo wrote:
> I can write ATA drivers for most hardware in a few days given 1. 
> actually useful datasheet 2. hardware at hand 3. an ENGINEER to talk to 
> when I get stuck.  So, sign me up.

Thanks, I'll add you to the list.

> It will be nice to have some central web site / wiki / whatever to 
> monitor progress, arbitrate jobs, provides link to relevant info and 
> people (probably some of them being open-by-request) and possibly 
> provide links to bugzilla entries.

So far most of the companies have not really wanted the publicity,
that's why I have not posted anything publically about it.  But I do
have a place to make all of this public if it turns out that it is ok to
do so.

thanks,

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

Re: Free Linux Driver Development!

[Tejun Heo]

Eric Sandeen wrote:

Jeff Garzik wrote:

Eric Sandeen wrote:

Jeff Garzik wrote:

Roland Dreier wrote:

And I seem to recall there's more SATA chipset documentation than Jeff
Garzik has time to implement support for.

I seriously doubt you can come up with even a single concrete example here.

Not trying to slight Jeff here in any way, but I thought I'd point out
one driver-less SATA chip that seems to have docs available.

When looking for a sata controller I came across several inexpensive
ones based on an Initio chipset, and at first glance it seems that they
have docs out there*: http://www.initio.com/products/sata.htm

but no drivers yet.  Just in case anyone is interested :)

The driver is in libata-dev.git#upstream and queued for 2.6.21.

Jeff


Woo!  that was fast.  Ok I stand corrected. :)


Be warned.  The driver is marked HIGHLY EXPERIMENTAL and it seem to work 
only on my machine.  Seems to have some problem with LBA48 support.


The datasheet initio posted on the website just contains register 
descriptions, which is much better than nothing but I still had to do a 
LOT of trial-and-error to make that thing quasi-working.  I've tried to 
contact them in many ways but couldn't get any response.  I'll probably 
get back to it in a few weeks.


I can write ATA drivers for most hardware in a few days given 1. 
actually useful datasheet 2. hardware at hand 3. an ENGINEER to talk to 
when I get stuck.  So, sign me up.


It will be nice to have some central web site / wiki / whatever to 
monitor progress, arbitrate jobs, provides link to relevant info and 
people (probably some of them being open-by-request) and possibly 
provide links to bugzilla entries.


--
tejun

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

Re: Free Linux Driver Development!

[Lennart Sorensen]

On Wed, Feb 07, 2007 at 07:03:26PM +0530, Sunil Naidu wrote:
> Yep, still floppies are useful. Example, when we buy a new device
> (driver) with a floppy (sometimes by manufacturer). Plus, from the
> customer (not user) POV, what's wrong in spending another $10 for a
> FDD in a typical $1000 PC? Makes sense right ;-)

Well certainly anyone with windows that needed a driver for their sata
controller better have a floppy drive (well apparenly vista now knows
about these amazing things called usb and optical drives... :).  I also
find them handy as an emergency grub boot method, although I guess most
new machines could boot that from cd if necesary.

Personally I just stick in a $25 floppy and usb memory card reader in
one.  Very handy, and doesn't waste space that way.

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

Re: Free Linux Driver Development!

[Sunil Naidu]

On 2/7/07, Akemi Yagi <[EMAIL PROTECTED]> wrote:

On Tue, 06 Feb 2007 19:07:50 +0530, Sunil Naidu wrote:

> On 2/5/07, Stefan Seyfried <[EMAIL PROTECTED]> wrote:
>> On Wed, Jan 31, 2007 at 03:14:31AM +0100, Adrian Bunk wrote:
>> > On Tue, Jan 30, 2007 at 05:24:28PM -0800, Greg KH wrote:
>>
>> Wrong. I abandoned all floppy drives some years ago. I'd actually vote
>> for removing the floppy driver from the kernel completely.
>
> I don't think time has come for that yet, still millions of people do use
> Floppy on Linux ;-)

So, I am not the only person on earth who still makes sure the floppy gets
included when building a new custom PC?


Yep, still floppies are useful. Example, when we buy a new device
(driver) with a floppy (sometimes by manufacturer). Plus, from the
customer (not user) POV, what's wrong in spending another $10 for a
FDD in a typical $1000 PC? Makes sense right ;-)



Akemi


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

Re: Free Linux Driver Development!

[Laurent Pinchart]

>  > > I have a Cisco USB webcam that supposedly conforms to the "USB Video
>  > > Device Class", but nothing happens when I plug it into my Linux box.
>  > > I assume the device class is specified as part of the USB spec...
>  >
>  > Are you sure?  That spec just came out not so long ago and I haven't
>  > seen any real devices support it just yet.  That said, I do know of a
>  > few people who are working on implementing the standard, try asking on
>  > the linux-usb-devel mailing list to find out what their status is.
>
> A quick web search finds http://linux-uvc.berlios.de/ but I don't see
> any signs that anyone plans to submit it upstream.

If you want a sign, here it is: I plan to submit the driver upstream :-)

After more than a year of development, the Linux UVC driver is now stable 
enough to be included in the kernel. There is a show stopper though: V4L2.

The UVC specification defines a set of standard controls. Most of them are 
part of the V4L2 specification as well (brightness, contrast, ...), but some 
of them aren't. Those controls are currently exposed through private controls 
(which drivers are allowed to expose by V4L2), but I don't want to keep 
private controls around for standard controls defined by UVC.

Once V4L2 will be updated (hopefully soon, I keep trying :-)), I will submit 
the driver upstream.

Regards,

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

Re: Free Linux Driver Development!

[Laurent Pinchart]

I have a Cisco USB webcam that supposedly conforms to the USB Video
Device Class, but nothing happens when I plug it into my Linux box.
I assume the device class is specified as part of the USB spec...
  
   Are you sure?  That spec just came out not so long ago and I haven't
   seen any real devices support it just yet.  That said, I do know of a
   few people who are working on implementing the standard, try asking on
   the linux-usb-devel mailing list to find out what their status is.

 A quick web search finds http://linux-uvc.berlios.de/ but I don't see
 any signs that anyone plans to submit it upstream.

If you want a sign, here it is: I plan to submit the driver upstream :-)

After more than a year of development, the Linux UVC driver is now stable 
enough to be included in the kernel. There is a show stopper though: V4L2.

The UVC specification defines a set of standard controls. Most of them are 
part of the V4L2 specification as well (brightness, contrast, ...), but some 
of them aren't. Those controls are currently exposed through private controls 
(which drivers are allowed to expose by V4L2), but I don't want to keep 
private controls around for standard controls defined by UVC.

Once V4L2 will be updated (hopefully soon, I keep trying :-)), I will submit 
the driver upstream.

Regards,

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

Re: Free Linux Driver Development!

[Sunil Naidu]

On 2/7/07, Akemi Yagi [EMAIL PROTECTED] wrote:

On Tue, 06 Feb 2007 19:07:50 +0530, Sunil Naidu wrote:

 On 2/5/07, Stefan Seyfried [EMAIL PROTECTED] wrote:
 On Wed, Jan 31, 2007 at 03:14:31AM +0100, Adrian Bunk wrote:
  On Tue, Jan 30, 2007 at 05:24:28PM -0800, Greg KH wrote:

 Wrong. I abandoned all floppy drives some years ago. I'd actually vote
 for removing the floppy driver from the kernel completely.

 I don't think time has come for that yet, still millions of people do use
 Floppy on Linux ;-)

So, I am not the only person on earth who still makes sure the floppy gets
included when building a new custom PC?


Yep, still floppies are useful. Example, when we buy a new device
(driver) with a floppy (sometimes by manufacturer). Plus, from the
customer (not user) POV, what's wrong in spending another $10 for a
FDD in a typical $1000 PC? Makes sense right ;-)



Akemi


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

Re: Free Linux Driver Development!

[Lennart Sorensen]

On Wed, Feb 07, 2007 at 07:03:26PM +0530, Sunil Naidu wrote:
 Yep, still floppies are useful. Example, when we buy a new device
 (driver) with a floppy (sometimes by manufacturer). Plus, from the
 customer (not user) POV, what's wrong in spending another $10 for a
 FDD in a typical $1000 PC? Makes sense right ;-)

Well certainly anyone with windows that needed a driver for their sata
controller better have a floppy drive (well apparenly vista now knows
about these amazing things called usb and optical drives... :).  I also
find them handy as an emergency grub boot method, although I guess most
new machines could boot that from cd if necesary.

Personally I just stick in a $25 floppy and usb memory card reader in
one.  Very handy, and doesn't waste space that way.

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

Re: Free Linux Driver Development!

[Tejun Heo]

Eric Sandeen wrote:

Jeff Garzik wrote:

Eric Sandeen wrote:

Jeff Garzik wrote:

Roland Dreier wrote:

And I seem to recall there's more SATA chipset documentation than Jeff
Garzik has time to implement support for.

I seriously doubt you can come up with even a single concrete example here.

Not trying to slight Jeff here in any way, but I thought I'd point out
one driver-less SATA chip that seems to have docs available.

When looking for a sata controller I came across several inexpensive
ones based on an Initio chipset, and at first glance it seems that they
have docs out there*: http://www.initio.com/products/sata.htm

but no drivers yet.  Just in case anyone is interested :)

The driver is in libata-dev.git#upstream and queued for 2.6.21.

Jeff


Woo!  that was fast.  Ok I stand corrected. :)


Be warned.  The driver is marked HIGHLY EXPERIMENTAL and it seem to work 
only on my machine.  Seems to have some problem with LBA48 support.


The datasheet initio posted on the website just contains register 
descriptions, which is much better than nothing but I still had to do a 
LOT of trial-and-error to make that thing quasi-working.  I've tried to 
contact them in many ways but couldn't get any response.  I'll probably 
get back to it in a few weeks.


I can write ATA drivers for most hardware in a few days given 1. 
actually useful datasheet 2. hardware at hand 3. an ENGINEER to talk to 
when I get stuck.  So, sign me up.


It will be nice to have some central web site / wiki / whatever to 
monitor progress, arbitrate jobs, provides link to relevant info and 
people (probably some of them being open-by-request) and possibly 
provide links to bugzilla entries.


--
tejun

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

Re: Free Linux Driver Development!

[Greg KH]

On Wed, Feb 07, 2007 at 06:03:58AM -0800, Tejun Heo wrote:
 I can write ATA drivers for most hardware in a few days given 1. 
 actually useful datasheet 2. hardware at hand 3. an ENGINEER to talk to 
 when I get stuck.  So, sign me up.

Thanks, I'll add you to the list.

 It will be nice to have some central web site / wiki / whatever to 
 monitor progress, arbitrate jobs, provides link to relevant info and 
 people (probably some of them being open-by-request) and possibly 
 provide links to bugzilla entries.

So far most of the companies have not really wanted the publicity,
that's why I have not posted anything publically about it.  But I do
have a place to make all of this public if it turns out that it is ok to
do so.

thanks,

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

Re: Free Linux Driver Development!

[Greg KH]

On Wed, Feb 07, 2007 at 08:12:05AM +0100, Miguel Ojeda wrote:
 
 As I'm not an expert in any kind of device, so I would like to join
 for any device which its type has not been assigned to any person yet
 (wild card?). Also, I would code for small LCDs.

Thanks, I've added you to the list.

I'll be doing a public update soon as people are wondering what is going
on :)

thanks,

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

Re: Free Linux Driver Development!

[David Lang]

On Tue, 6 Feb 2007, Akemi Yagi wrote:


On Tue, 06 Feb 2007 19:07:50 +0530, Sunil Naidu wrote:


On 2/5/07, Stefan Seyfried [EMAIL PROTECTED] wrote:

On Wed, Jan 31, 2007 at 03:14:31AM +0100, Adrian Bunk wrote:

On Tue, Jan 30, 2007 at 05:24:28PM -0800, Greg KH wrote:


Wrong. I abandoned all floppy drives some years ago. I'd actually vote
for removing the floppy driver from the kernel completely.


I don't think time has come for that yet, still millions of people do use
Floppy on Linux ;-)


So, I am not the only person on earth who still makes sure the floppy gets
included when building a new custom PC?


No, I've avoided useing vendors that don't offer it as an option.

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

Re: Free Linux Driver Development!

[Miguel Ojeda]

On 2/6/07, Greg KH <[EMAIL PROTECTED]> wrote:

On Tue, Feb 06, 2007 at 12:29:03PM +0400, Manu Abraham wrote:
> On 2/6/07, Greg KH <[EMAIL PROTECTED]> wrote:
> >On Sun, Feb 04, 2007 at 07:59:47PM +0100, Pierre Ossman wrote:
> >> Hi Greg,
> >>
> >> Although I am a bit of a cynic, I really hope that this endeavor works
> >> the way you hope.
> >>
> >> I'd also like to offer my services to this quest of yours. If you get
> >> any SD, MMC or SDIO requests, feel free to pass them along to me. I am
> >> not a big fan of debug-by-email though, so I'd prefer vendors who
either
> >> can provide samples or where the hardware is cheap and freely available
> >> so I can just go out and by one.
> >
> >Great, thanks for letting me know, I've added you to the list.
>
> for any DVB/DAB/DMB (PCI based) devices, if any vendors would like to
> offer sample device and specs, would like to join the bandwagon.

thanks, I've added you to the list.

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



As I'm not an expert in any kind of device, so I would like to join
for any device which its type has not been assigned to any person yet
(wild card?). Also, I would code for small LCDs.

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

floppy (Re: Free Linux Driver Development!, OT)

[Oleg Verych]

> From: Akemi Yagi
> Newsgroups: gmane.linux.kernel
> Subject: Re: Free Linux Driver Development!
> Date: Tue, 06 Feb 2007 13:14:44 -0800

[]
>> I don't think time has come for that yet, still millions of people do use
>> Floppy on Linux ;-)
>
> So, I am not the only person on earth who still makes sure the floppy gets
> included when building a new custom PC?

I wonder, why i've said good bye to my floppy drive by steel *hammer*,
after i've got cd-rw?

And i do more, when reading posts like that, after i'm having nG usb-flash
on my keyring for years...



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

Re: Free Linux Driver Development!

[Akemi Yagi]

On Tue, 06 Feb 2007 19:07:50 +0530, Sunil Naidu wrote:

> On 2/5/07, Stefan Seyfried <[EMAIL PROTECTED]> wrote:
>> On Wed, Jan 31, 2007 at 03:14:31AM +0100, Adrian Bunk wrote:
>> > On Tue, Jan 30, 2007 at 05:24:28PM -0800, Greg KH wrote:
>>
>> Wrong. I abandoned all floppy drives some years ago. I'd actually vote
>> for removing the floppy driver from the kernel completely.
> 
> I don't think time has come for that yet, still millions of people do use
> Floppy on Linux ;-)

So, I am not the only person on earth who still makes sure the floppy gets
included when building a new custom PC?

Akemi

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

Re: Free Linux Driver Development!

[Greg KH]

On Tue, Feb 06, 2007 at 12:29:03PM +0400, Manu Abraham wrote:
> On 2/6/07, Greg KH <[EMAIL PROTECTED]> wrote:
> >On Sun, Feb 04, 2007 at 07:59:47PM +0100, Pierre Ossman wrote:
> >> Hi Greg,
> >>
> >> Although I am a bit of a cynic, I really hope that this endeavor works
> >> the way you hope.
> >>
> >> I'd also like to offer my services to this quest of yours. If you get
> >> any SD, MMC or SDIO requests, feel free to pass them along to me. I am
> >> not a big fan of debug-by-email though, so I'd prefer vendors who either
> >> can provide samples or where the hardware is cheap and freely available
> >> so I can just go out and by one.
> >
> >Great, thanks for letting me know, I've added you to the list.
> 
> for any DVB/DAB/DMB (PCI based) devices, if any vendors would like to
> offer sample device and specs, would like to join the bandwagon.

thanks, I've added you to the list.

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

Re: Free Linux Driver Development!

[Greg KH]

On Tue, Feb 06, 2007 at 07:05:10PM +0530, Sunil Naidu wrote:
> >Just let me know what types of devices you are interested in working on.
> 
> I would love to work on PC as well as Embedded stuff (Power, Intel, and 
> ARM).
> Devices types - Audio/Video (this needs special attention for the
> Linux Desktop), USB (TV Tuner card, key for Linux Desktop), Bluetooth
> (Mobiles) , GSM/GPRS/WiFi/WIMAX (my self R area).  Plus any device
> which we think important to boost Linux Desktop ;-)

Thanks, I've added you to to the list.

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

Re: Free Linux Driver Development!

[Gene Heskett]

On Tuesday 06 February 2007 11:30, Gene Heskett wrote:
>On Tuesday 06 February 2007 08:37, Sunil Naidu wrote:
>>On 2/5/07, Stefan Seyfried <[EMAIL PROTECTED]> wrote:
>>> On Wed, Jan 31, 2007 at 03:14:31AM +0100, Adrian Bunk wrote:
>>> > On Tue, Jan 30, 2007 at 05:24:28PM -0800, Greg KH wrote:
>>>
>>> Wrong. I abandoned all floppy drives some years ago. I'd actually
>>> vote for removing the floppy driver from the kernel completely.
>>
>>I don't think time has come for that yet, still millions of people do
>>use Floppy on Linux ;-)
>>Maybe by 2.6.30 or so...
>
>How about not even then?  There are few uses for the floppy drive today
>within linux, this is true.  BUT, that floppy is often the only was

Gahh, s/was/way above.  Old fingers seem to have minds of their own... :)

>software can be gotten from a vintage computer and published, or from a
>publishing site back to that vintage computer.  Please don't take away
>our last data path to what is to many of us, a very old and trusted dear
>friend.  OS9, and later Nitros9, on a TRS-80 Color Computer, was my
>teacher about unix-like systems, running a multiuser/multitasking
>operating system on a machine with only 64k of ram, although my current
>machine has 2 megs in it.  And I occasionally still miss some of the
>things I could do on that little machine that I have not been able to do
>since, like start an assembly that generates an output listing, and
>switch to another monitor or window & list that listing to the screen a
>maximum of 256 bytes behind the writing of that listing to the disk file
>it was going to.
>
>The floppy may not be usefull to linux anymore, but in support of other
>older formats, it is priceless.
>
>>> Stefan Seyfried
>>
>>~Akula2
>>-
>>To unsubscribe from this list: send the line "unsubscribe linux-kernel"
>> in the body of a message to [EMAIL PROTECTED]
>>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>Please read the FAQ at  http://www.tux.org/lkml/

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2007 by Maurice Eugene Heskett, all rights reserved.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Gene Heskett]

On Tuesday 06 February 2007 08:37, Sunil Naidu wrote:
>On 2/5/07, Stefan Seyfried <[EMAIL PROTECTED]> wrote:
>> On Wed, Jan 31, 2007 at 03:14:31AM +0100, Adrian Bunk wrote:
>> > On Tue, Jan 30, 2007 at 05:24:28PM -0800, Greg KH wrote:
>>
>> Wrong. I abandoned all floppy drives some years ago. I'd actually
>> vote for removing the floppy driver from the kernel completely.
>
>I don't think time has come for that yet, still millions of people do
>use Floppy on Linux ;-)
>Maybe by 2.6.30 or so...

How about not even then?  There are few uses for the floppy drive today 
within linux, this is true.  BUT, that floppy is often the only was 
software can be gotten from a vintage computer and published, or from a 
publishing site back to that vintage computer.  Please don't take away 
our last data path to what is to many of us, a very old and trusted dear 
friend.  OS9, and later Nitros9, on a TRS-80 Color Computer, was my 
teacher about unix-like systems, running a multiuser/multitasking 
operating system on a machine with only 64k of ram, although my current 
machine has 2 megs in it.  And I occasionally still miss some of the 
things I could do on that little machine that I have not been able to do 
since, like start an assembly that generates an output listing, and 
switch to another monitor or window & list that listing to the screen a 
maximum of 256 bytes behind the writing of that listing to the disk file 
it was going to.

The floppy may not be usefull to linux anymore, but in support of other 
older formats, it is priceless.
 
>> Stefan Seyfried
>
>~Akula2
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in the body of a message to [EMAIL PROTECTED]
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2007 by Maurice Eugene Heskett, all rights reserved.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Stefan Seyfried]

On Tue, Feb 06, 2007 at 10:12:04AM -0500, Bill Davidsen wrote:
> Stefan Seyfried wrote:
> >On Wed, Jan 31, 2007 at 03:14:31AM +0100, Adrian Bunk wrote:
> >>On Tue, Jan 30, 2007 at 05:24:28PM -0800, Greg KH wrote:
> >>>What?  Throw a fresh-faced newbie instantly into the tar-pit of despair
> >>>that floppy.c is?  Do you want everyone just to run screaming from
> >>>kernel development never to be seen again?
> >>>
> >>>:)
> >>Other than with the ISA drivers example, at least everyone has the 
> >>hardware... ;-)
> >Wrong. I abandoned all floppy drives some years ago. I'd actually
> >vote for removing the floppy driver from the kernel completely.
> 
> Is that your model of how the kernel should work? Take out anything you don't 
> personally need?

Oh. I must have forgotten those smilies.
;-)

> I'm guesstimating the 20-30% of the old laptops I rehab on Linux for kids who 
> have none lack the 
> ability to boot off CD. Or write a CD, for that matter. The ability of Linux 
> to run on old 
> hardware is another advantage over commercial systems.

Yes, i know.
-- 
Stefan Seyfried
QA / R Team Mobile Devices|  "Any ideas, John?"
SUSE LINUX Products GmbH, Nürnberg  | "Well, surrounding them's out." 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Bill Davidsen]

Stefan Seyfried wrote:

On Wed, Jan 31, 2007 at 03:14:31AM +0100, Adrian Bunk wrote:

On Tue, Jan 30, 2007 at 05:24:28PM -0800, Greg KH wrote:



What?  Throw a fresh-faced newbie instantly into the tar-pit of despair
that floppy.c is?  Do you want everyone just to run screaming from
kernel development never to be seen again?

:)
Other than with the ISA drivers example, at least everyone has the 
hardware... ;-)


Wrong. I abandoned all floppy drives some years ago. I'd actually
vote for removing the floppy driver from the kernel completely.


Is that your model of how the kernel should work? Take out anything you 
don't personally need?


I'm guesstimating the 20-30% of the old laptops I rehab on Linux for 
kids who have none lack the ability to boot off CD. Or write a CD, for 
that matter. The ability of Linux to run on old hardware is another 
advantage over commercial systems.


Well, at work i probably have an USB floppy lying around somewhere,
but i doubt that it uses floppy.c ;-), 



--
Bill Davidsen <[EMAIL PROTECTED]>
  "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Dave Jones]

On Tue, Feb 06, 2007 at 07:07:50PM +0530, Sunil Naidu wrote:
 > On 2/5/07, Stefan Seyfried <[EMAIL PROTECTED]> wrote:
 > > On Wed, Jan 31, 2007 at 03:14:31AM +0100, Adrian Bunk wrote:
 > > > On Tue, Jan 30, 2007 at 05:24:28PM -0800, Greg KH wrote:
 > >
 > > Wrong. I abandoned all floppy drives some years ago. I'd actually
 > > vote for removing the floppy driver from the kernel completely.
 > 
 > I don't think time has come for that yet, still millions of people do
 > use Floppy on Linux ;-)
 > Maybe by 2.6.30 or so...

The release of any new kernel doesn't make all existing hardware
on the planet stop working.  I still get requests to enable
drivers in the Fedora kernel for 10 year old ISA sound cards.

In some parts of the world, buying a new computer isn't an option.
One of Linux's strengths is that we keep working on old hardware
without forcing the user to upgrade their system every time
like certain commercial OS's.

Dave

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

Re: Free Linux Driver Development!

[Sunil Naidu]

On 2/5/07, Stefan Seyfried <[EMAIL PROTECTED]> wrote:

On Wed, Jan 31, 2007 at 03:14:31AM +0100, Adrian Bunk wrote:
> On Tue, Jan 30, 2007 at 05:24:28PM -0800, Greg KH wrote:

Wrong. I abandoned all floppy drives some years ago. I'd actually
vote for removing the floppy driver from the kernel completely.


I don't think time has come for that yet, still millions of people do
use Floppy on Linux ;-)
Maybe by 2.6.30 or so...



Stefan Seyfried


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

Re: Free Linux Driver Development!

[Sunil Naidu]

> On 2/4/07, Greg KH <[EMAIL PROTECTED]> wrote:
> >
> >Just let me know if you are interested in participating, and what types
> >of devices you wish to write drivers for (USB, PCI, network, etc.)


Yep, would love to dive into this oceanin available mode ;-)


> I would like to participate; however, for people who is not at USA
> (say, Europe), are there fair chances to get samples of devices to
> work with?

Not all of the companies asking for this work are in the US, so I don't
see any reason why we should limit our developers to just one country,
that wouldn't be very fair...


That's correct. There should be developers across many regions. For
example, PC growth has the highest in Asia - so more users - hence the
demand for device support !

Plus, there is huge demand coming in 2 important areas - Embedded &
Mobile space.


Just let me know what types of devices you are interested in working on.


I would love to work on PC as well as Embedded stuff (Power, Intel, and ARM).
Devices types - Audio/Video (this needs special attention for the
Linux Desktop), USB (TV Tuner card, key for Linux Desktop), Bluetooth
(Mobiles) , GSM/GPRS/WiFi/WIMAX (my self R area).  Plus any device
which we think important to boost Linux Desktop ;-)


thanks,

greg k-h


Thank you too,

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

Re: Free Linux Driver Development!

[Manu Abraham]

On 2/6/07, Greg KH <[EMAIL PROTECTED]> wrote:

On Sun, Feb 04, 2007 at 07:59:47PM +0100, Pierre Ossman wrote:
> Hi Greg,
>
> Although I am a bit of a cynic, I really hope that this endeavor works
> the way you hope.
>
> I'd also like to offer my services to this quest of yours. If you get
> any SD, MMC or SDIO requests, feel free to pass them along to me. I am
> not a big fan of debug-by-email though, so I'd prefer vendors who either
> can provide samples or where the hardware is cheap and freely available
> so I can just go out and by one.

Great, thanks for letting me know, I've added you to the list.


for any DVB/DAB/DMB (PCI based) devices, if any vendors would like to
offer sample device and specs, would like to join the bandwagon.

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

Re: Free Linux Driver Development!

[Manu Abraham]

On 2/6/07, Greg KH [EMAIL PROTECTED] wrote:

On Sun, Feb 04, 2007 at 07:59:47PM +0100, Pierre Ossman wrote:
 Hi Greg,

 Although I am a bit of a cynic, I really hope that this endeavor works
 the way you hope.

 I'd also like to offer my services to this quest of yours. If you get
 any SD, MMC or SDIO requests, feel free to pass them along to me. I am
 not a big fan of debug-by-email though, so I'd prefer vendors who either
 can provide samples or where the hardware is cheap and freely available
 so I can just go out and by one.

Great, thanks for letting me know, I've added you to the list.


for any DVB/DAB/DMB (PCI based) devices, if any vendors would like to
offer sample device and specs, would like to join the bandwagon.

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

Re: Free Linux Driver Development!

[Sunil Naidu]

 On 2/4/07, Greg KH [EMAIL PROTECTED] wrote:
 
 Just let me know if you are interested in participating, and what types
 of devices you wish to write drivers for (USB, PCI, network, etc.)


Yep, would love to dive into this oceanin available mode ;-)


 I would like to participate; however, for people who is not at USA
 (say, Europe), are there fair chances to get samples of devices to
 work with?

Not all of the companies asking for this work are in the US, so I don't
see any reason why we should limit our developers to just one country,
that wouldn't be very fair...


That's correct. There should be developers across many regions. For
example, PC growth has the highest in Asia - so more users - hence the
demand for device support !

Plus, there is huge demand coming in 2 important areas - Embedded 
Mobile space.


Just let me know what types of devices you are interested in working on.


I would love to work on PC as well as Embedded stuff (Power, Intel, and ARM).
Devices types - Audio/Video (this needs special attention for the
Linux Desktop), USB (TV Tuner card, key for Linux Desktop), Bluetooth
(Mobiles) , GSM/GPRS/WiFi/WIMAX (my self RD area).  Plus any device
which we think important to boost Linux Desktop ;-)


thanks,

greg k-h


Thank you too,

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

Re: Free Linux Driver Development!

[Sunil Naidu]

On 2/5/07, Stefan Seyfried [EMAIL PROTECTED] wrote:

On Wed, Jan 31, 2007 at 03:14:31AM +0100, Adrian Bunk wrote:
 On Tue, Jan 30, 2007 at 05:24:28PM -0800, Greg KH wrote:

Wrong. I abandoned all floppy drives some years ago. I'd actually
vote for removing the floppy driver from the kernel completely.


I don't think time has come for that yet, still millions of people do
use Floppy on Linux ;-)
Maybe by 2.6.30 or so...



Stefan Seyfried


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

Re: Free Linux Driver Development!

[Dave Jones]

On Tue, Feb 06, 2007 at 07:07:50PM +0530, Sunil Naidu wrote:
  On 2/5/07, Stefan Seyfried [EMAIL PROTECTED] wrote:
   On Wed, Jan 31, 2007 at 03:14:31AM +0100, Adrian Bunk wrote:
On Tue, Jan 30, 2007 at 05:24:28PM -0800, Greg KH wrote:
  
   Wrong. I abandoned all floppy drives some years ago. I'd actually
   vote for removing the floppy driver from the kernel completely.
  
  I don't think time has come for that yet, still millions of people do
  use Floppy on Linux ;-)
  Maybe by 2.6.30 or so...

The release of any new kernel doesn't make all existing hardware
on the planet stop working.  I still get requests to enable
drivers in the Fedora kernel for 10 year old ISA sound cards.

In some parts of the world, buying a new computer isn't an option.
One of Linux's strengths is that we keep working on old hardware
without forcing the user to upgrade their system every time
like certain commercial OS's.

Dave

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

Re: Free Linux Driver Development!

[Bill Davidsen]

Stefan Seyfried wrote:

On Wed, Jan 31, 2007 at 03:14:31AM +0100, Adrian Bunk wrote:

On Tue, Jan 30, 2007 at 05:24:28PM -0800, Greg KH wrote:



What?  Throw a fresh-faced newbie instantly into the tar-pit of despair
that floppy.c is?  Do you want everyone just to run screaming from
kernel development never to be seen again?

:)
Other than with the ISA drivers example, at least everyone has the 
hardware... ;-)


Wrong. I abandoned all floppy drives some years ago. I'd actually
vote for removing the floppy driver from the kernel completely.


Is that your model of how the kernel should work? Take out anything you 
don't personally need?


I'm guesstimating the 20-30% of the old laptops I rehab on Linux for 
kids who have none lack the ability to boot off CD. Or write a CD, for 
that matter. The ability of Linux to run on old hardware is another 
advantage over commercial systems.


Well, at work i probably have an USB floppy lying around somewhere,
but i doubt that it uses floppy.c ;-), 



--
Bill Davidsen [EMAIL PROTECTED]
  We have more to fear from the bungling of the incompetent than from
the machinations of the wicked.  - from Slashdot
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Stefan Seyfried]

On Tue, Feb 06, 2007 at 10:12:04AM -0500, Bill Davidsen wrote:
 Stefan Seyfried wrote:
 On Wed, Jan 31, 2007 at 03:14:31AM +0100, Adrian Bunk wrote:
 On Tue, Jan 30, 2007 at 05:24:28PM -0800, Greg KH wrote:
 What?  Throw a fresh-faced newbie instantly into the tar-pit of despair
 that floppy.c is?  Do you want everyone just to run screaming from
 kernel development never to be seen again?
 
 :)
 Other than with the ISA drivers example, at least everyone has the 
 hardware... ;-)
 Wrong. I abandoned all floppy drives some years ago. I'd actually
 vote for removing the floppy driver from the kernel completely.
 
 Is that your model of how the kernel should work? Take out anything you don't 
 personally need?

Oh. I must have forgotten those smilies.
;-)

 I'm guesstimating the 20-30% of the old laptops I rehab on Linux for kids who 
 have none lack the 
 ability to boot off CD. Or write a CD, for that matter. The ability of Linux 
 to run on old 
 hardware is another advantage over commercial systems.

Yes, i know.
-- 
Stefan Seyfried
QA / RD Team Mobile Devices|  Any ideas, John?
SUSE LINUX Products GmbH, Nürnberg  | Well, surrounding them's out. 
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Gene Heskett]

On Tuesday 06 February 2007 08:37, Sunil Naidu wrote:
On 2/5/07, Stefan Seyfried [EMAIL PROTECTED] wrote:
 On Wed, Jan 31, 2007 at 03:14:31AM +0100, Adrian Bunk wrote:
  On Tue, Jan 30, 2007 at 05:24:28PM -0800, Greg KH wrote:

 Wrong. I abandoned all floppy drives some years ago. I'd actually
 vote for removing the floppy driver from the kernel completely.

I don't think time has come for that yet, still millions of people do
use Floppy on Linux ;-)
Maybe by 2.6.30 or so...

How about not even then?  There are few uses for the floppy drive today 
within linux, this is true.  BUT, that floppy is often the only was 
software can be gotten from a vintage computer and published, or from a 
publishing site back to that vintage computer.  Please don't take away 
our last data path to what is to many of us, a very old and trusted dear 
friend.  OS9, and later Nitros9, on a TRS-80 Color Computer, was my 
teacher about unix-like systems, running a multiuser/multitasking 
operating system on a machine with only 64k of ram, although my current 
machine has 2 megs in it.  And I occasionally still miss some of the 
things I could do on that little machine that I have not been able to do 
since, like start an assembly that generates an output listing, and 
switch to another monitor or window  list that listing to the screen a 
maximum of 256 bytes behind the writing of that listing to the disk file 
it was going to.

The floppy may not be usefull to linux anymore, but in support of other 
older formats, it is priceless.
 
 Stefan Seyfried

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

-- 
Cheers, Gene
There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order.
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2007 by Maurice Eugene Heskett, all rights reserved.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Gene Heskett]

On Tuesday 06 February 2007 11:30, Gene Heskett wrote:
On Tuesday 06 February 2007 08:37, Sunil Naidu wrote:
On 2/5/07, Stefan Seyfried [EMAIL PROTECTED] wrote:
 On Wed, Jan 31, 2007 at 03:14:31AM +0100, Adrian Bunk wrote:
  On Tue, Jan 30, 2007 at 05:24:28PM -0800, Greg KH wrote:

 Wrong. I abandoned all floppy drives some years ago. I'd actually
 vote for removing the floppy driver from the kernel completely.

I don't think time has come for that yet, still millions of people do
use Floppy on Linux ;-)
Maybe by 2.6.30 or so...

How about not even then?  There are few uses for the floppy drive today
within linux, this is true.  BUT, that floppy is often the only was

Gahh, s/was/way above.  Old fingers seem to have minds of their own... :)

software can be gotten from a vintage computer and published, or from a
publishing site back to that vintage computer.  Please don't take away
our last data path to what is to many of us, a very old and trusted dear
friend.  OS9, and later Nitros9, on a TRS-80 Color Computer, was my
teacher about unix-like systems, running a multiuser/multitasking
operating system on a machine with only 64k of ram, although my current
machine has 2 megs in it.  And I occasionally still miss some of the
things I could do on that little machine that I have not been able to do
since, like start an assembly that generates an output listing, and
switch to another monitor or window  list that listing to the screen a
maximum of 256 bytes behind the writing of that listing to the disk file
it was going to.

The floppy may not be usefull to linux anymore, but in support of other
older formats, it is priceless.

 Stefan Seyfried

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

-- 
Cheers, Gene
There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order.
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2007 by Maurice Eugene Heskett, all rights reserved.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Greg KH]

On Tue, Feb 06, 2007 at 07:05:10PM +0530, Sunil Naidu wrote:
 Just let me know what types of devices you are interested in working on.
 
 I would love to work on PC as well as Embedded stuff (Power, Intel, and 
 ARM).
 Devices types - Audio/Video (this needs special attention for the
 Linux Desktop), USB (TV Tuner card, key for Linux Desktop), Bluetooth
 (Mobiles) , GSM/GPRS/WiFi/WIMAX (my self RD area).  Plus any device
 which we think important to boost Linux Desktop ;-)

Thanks, I've added you to to the list.

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

Re: Free Linux Driver Development!

[Greg KH]

On Tue, Feb 06, 2007 at 12:29:03PM +0400, Manu Abraham wrote:
 On 2/6/07, Greg KH [EMAIL PROTECTED] wrote:
 On Sun, Feb 04, 2007 at 07:59:47PM +0100, Pierre Ossman wrote:
  Hi Greg,
 
  Although I am a bit of a cynic, I really hope that this endeavor works
  the way you hope.
 
  I'd also like to offer my services to this quest of yours. If you get
  any SD, MMC or SDIO requests, feel free to pass them along to me. I am
  not a big fan of debug-by-email though, so I'd prefer vendors who either
  can provide samples or where the hardware is cheap and freely available
  so I can just go out and by one.
 
 Great, thanks for letting me know, I've added you to the list.
 
 for any DVB/DAB/DMB (PCI based) devices, if any vendors would like to
 offer sample device and specs, would like to join the bandwagon.

thanks, I've added you to the list.

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

Re: Free Linux Driver Development!

[Akemi Yagi]

On Tue, 06 Feb 2007 19:07:50 +0530, Sunil Naidu wrote:

 On 2/5/07, Stefan Seyfried [EMAIL PROTECTED] wrote:
 On Wed, Jan 31, 2007 at 03:14:31AM +0100, Adrian Bunk wrote:
  On Tue, Jan 30, 2007 at 05:24:28PM -0800, Greg KH wrote:

 Wrong. I abandoned all floppy drives some years ago. I'd actually vote
 for removing the floppy driver from the kernel completely.
 
 I don't think time has come for that yet, still millions of people do use
 Floppy on Linux ;-)

So, I am not the only person on earth who still makes sure the floppy gets
included when building a new custom PC?

Akemi

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

floppy (Re: Free Linux Driver Development!, OT)

[Oleg Verych]

 From: Akemi Yagi
 Newsgroups: gmane.linux.kernel
 Subject: Re: Free Linux Driver Development!
 Date: Tue, 06 Feb 2007 13:14:44 -0800

[]
 I don't think time has come for that yet, still millions of people do use
 Floppy on Linux ;-)

 So, I am not the only person on earth who still makes sure the floppy gets
 included when building a new custom PC?

I wonder, why i've said good bye to my floppy drive by steel *hammer*,
after i've got cd-rw?

And i do more, when reading posts like that, after i'm having nG usb-flash
on my keyring for years...



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

Re: Free Linux Driver Development!

[Miguel Ojeda]

On 2/6/07, Greg KH [EMAIL PROTECTED] wrote:

On Tue, Feb 06, 2007 at 12:29:03PM +0400, Manu Abraham wrote:
 On 2/6/07, Greg KH [EMAIL PROTECTED] wrote:
 On Sun, Feb 04, 2007 at 07:59:47PM +0100, Pierre Ossman wrote:
  Hi Greg,
 
  Although I am a bit of a cynic, I really hope that this endeavor works
  the way you hope.
 
  I'd also like to offer my services to this quest of yours. If you get
  any SD, MMC or SDIO requests, feel free to pass them along to me. I am
  not a big fan of debug-by-email though, so I'd prefer vendors who
either
  can provide samples or where the hardware is cheap and freely available
  so I can just go out and by one.
 
 Great, thanks for letting me know, I've added you to the list.

 for any DVB/DAB/DMB (PCI based) devices, if any vendors would like to
 offer sample device and specs, would like to join the bandwagon.

thanks, I've added you to the list.

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



As I'm not an expert in any kind of device, so I would like to join
for any device which its type has not been assigned to any person yet
(wild card?). Also, I would code for small LCDs.

--
Miguel Ojeda
http://maxextreme.googlepages.com/index.htm
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Greg KH]

On Sun, Feb 04, 2007 at 07:59:47PM +0100, Pierre Ossman wrote:
> Hi Greg,
> 
> Although I am a bit of a cynic, I really hope that this endeavor works
> the way you hope.
> 
> I'd also like to offer my services to this quest of yours. If you get
> any SD, MMC or SDIO requests, feel free to pass them along to me. I am
> not a big fan of debug-by-email though, so I'd prefer vendors who either
> can provide samples or where the hardware is cheap and freely available
> so I can just go out and by one.

Great, thanks for letting me know, I've added you to the list.

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

Re: Free Linux Driver Development!

[Greg KH]

On Mon, Feb 05, 2007 at 04:24:21PM +0100, Jiri Slaby wrote:
> Greg KH napsal(a):
> >On Sun, Feb 04, 2007 at 08:08:32PM +0100, Miguel Ojeda wrote:
> >>On 2/4/07, Greg KH <[EMAIL PROTECTED]> wrote:
> >>>Just let me know if you are interested in participating, and what types
> >>>of devices you wish to write drivers for (USB, PCI, network, etc.)
> >>I would like to participate; however, for people who is not at USA
> >>(say, Europe), are there fair chances to get samples of devices to
> >>work with?
> >
> >Not all of the companies asking for this work are in the US, so I don't
> >see any reason why we should limit our developers to just one country,
> >that wouldn't be very fair...
> >
> >Just let me know what types of devices you are interested in working on.
> 
> Then, I want to be involved too. I'm interested in PCI and network devices.

Thanks, I've added you to the list.

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

Re: Free Linux Driver Development!

[Jiri Slaby]

Greg KH napsal(a):

On Sun, Feb 04, 2007 at 08:08:32PM +0100, Miguel Ojeda wrote:

On 2/4/07, Greg KH <[EMAIL PROTECTED]> wrote:

Just let me know if you are interested in participating, and what types
of devices you wish to write drivers for (USB, PCI, network, etc.)

I would like to participate; however, for people who is not at USA
(say, Europe), are there fair chances to get samples of devices to
work with?


Not all of the companies asking for this work are in the US, so I don't
see any reason why we should limit our developers to just one country,
that wouldn't be very fair...

Just let me know what types of devices you are interested in working on.


Then, I want to be involved too. I'm interested in PCI and network devices.

thanks,
--
http://www.fi.muni.cz/~xslaby/Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8  22A0 32CC 55C3 39D4 7A7E
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Stefan Seyfried]

On Wed, Jan 31, 2007 at 03:14:31AM +0100, Adrian Bunk wrote:
> On Tue, Jan 30, 2007 at 05:24:28PM -0800, Greg KH wrote:

> > What?  Throw a fresh-faced newbie instantly into the tar-pit of despair
> > that floppy.c is?  Do you want everyone just to run screaming from
> > kernel development never to be seen again?
> > 
> > :)
> 
> Other than with the ISA drivers example, at least everyone has the 
> hardware... ;-)

Wrong. I abandoned all floppy drives some years ago. I'd actually
vote for removing the floppy driver from the kernel completely.

Well, at work i probably have an USB floppy lying around somewhere,
but i doubt that it uses floppy.c ;-), 
-- 
Stefan Seyfried
QA / R Team Mobile Devices|  "Any ideas, John?"
SUSE LINUX Products GmbH, Nürnberg  | "Well, surrounding them's out." 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Greg KH]

On Sun, Feb 04, 2007 at 08:08:32PM +0100, Miguel Ojeda wrote:
> On 2/4/07, Greg KH <[EMAIL PROTECTED]> wrote:
> >
> >Just let me know if you are interested in participating, and what types
> >of devices you wish to write drivers for (USB, PCI, network, etc.)
> >
> >thanks,
> >
> >greg k-h
> >
> 
> I would like to participate; however, for people who is not at USA
> (say, Europe), are there fair chances to get samples of devices to
> work with?

Not all of the companies asking for this work are in the US, so I don't
see any reason why we should limit our developers to just one country,
that wouldn't be very fair...

Just let me know what types of devices you are interested in working on.

thanks,

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

Re: Free Linux Driver Development!

[Greg KH]

On Sun, Feb 04, 2007 at 08:08:32PM +0100, Miguel Ojeda wrote:
 On 2/4/07, Greg KH [EMAIL PROTECTED] wrote:
 
 Just let me know if you are interested in participating, and what types
 of devices you wish to write drivers for (USB, PCI, network, etc.)
 
 thanks,
 
 greg k-h
 
 
 I would like to participate; however, for people who is not at USA
 (say, Europe), are there fair chances to get samples of devices to
 work with?

Not all of the companies asking for this work are in the US, so I don't
see any reason why we should limit our developers to just one country,
that wouldn't be very fair...

Just let me know what types of devices you are interested in working on.

thanks,

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

Re: Free Linux Driver Development!

[Stefan Seyfried]

On Wed, Jan 31, 2007 at 03:14:31AM +0100, Adrian Bunk wrote:
 On Tue, Jan 30, 2007 at 05:24:28PM -0800, Greg KH wrote:

  What?  Throw a fresh-faced newbie instantly into the tar-pit of despair
  that floppy.c is?  Do you want everyone just to run screaming from
  kernel development never to be seen again?
  
  :)
 
 Other than with the ISA drivers example, at least everyone has the 
 hardware... ;-)

Wrong. I abandoned all floppy drives some years ago. I'd actually
vote for removing the floppy driver from the kernel completely.

Well, at work i probably have an USB floppy lying around somewhere,
but i doubt that it uses floppy.c ;-), 
-- 
Stefan Seyfried
QA / RD Team Mobile Devices|  Any ideas, John?
SUSE LINUX Products GmbH, Nürnberg  | Well, surrounding them's out. 
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Jiri Slaby]

Greg KH napsal(a):

On Sun, Feb 04, 2007 at 08:08:32PM +0100, Miguel Ojeda wrote:

On 2/4/07, Greg KH [EMAIL PROTECTED] wrote:

Just let me know if you are interested in participating, and what types
of devices you wish to write drivers for (USB, PCI, network, etc.)

I would like to participate; however, for people who is not at USA
(say, Europe), are there fair chances to get samples of devices to
work with?


Not all of the companies asking for this work are in the US, so I don't
see any reason why we should limit our developers to just one country,
that wouldn't be very fair...

Just let me know what types of devices you are interested in working on.


Then, I want to be involved too. I'm interested in PCI and network devices.

thanks,
--
http://www.fi.muni.cz/~xslaby/Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8  22A0 32CC 55C3 39D4 7A7E
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Greg KH]

On Mon, Feb 05, 2007 at 04:24:21PM +0100, Jiri Slaby wrote:
 Greg KH napsal(a):
 On Sun, Feb 04, 2007 at 08:08:32PM +0100, Miguel Ojeda wrote:
 On 2/4/07, Greg KH [EMAIL PROTECTED] wrote:
 Just let me know if you are interested in participating, and what types
 of devices you wish to write drivers for (USB, PCI, network, etc.)
 I would like to participate; however, for people who is not at USA
 (say, Europe), are there fair chances to get samples of devices to
 work with?
 
 Not all of the companies asking for this work are in the US, so I don't
 see any reason why we should limit our developers to just one country,
 that wouldn't be very fair...
 
 Just let me know what types of devices you are interested in working on.
 
 Then, I want to be involved too. I'm interested in PCI and network devices.

Thanks, I've added you to the list.

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

Re: Free Linux Driver Development!

[Greg KH]

On Sun, Feb 04, 2007 at 07:59:47PM +0100, Pierre Ossman wrote:
 Hi Greg,
 
 Although I am a bit of a cynic, I really hope that this endeavor works
 the way you hope.
 
 I'd also like to offer my services to this quest of yours. If you get
 any SD, MMC or SDIO requests, feel free to pass them along to me. I am
 not a big fan of debug-by-email though, so I'd prefer vendors who either
 can provide samples or where the hardware is cheap and freely available
 so I can just go out and by one.

Great, thanks for letting me know, I've added you to the list.

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

Re: Free Linux Driver Development!

[Oleg Verych]

> From: devzero web.de
> Newsgroups: gmane.linux.kernel
> Subject: Re: Free Linux Driver Development!
> Date: Sun, 04 Feb 2007 22:37:33 +0100
> Organization: http://freemail.web.de/
> Archived-At: <http://permalink.gmane.org/gmane.linux.kernel/489586>

> First off, compliments to this announcement, I liked it very much!
>
> Some comment regarding those "volunteers, waiting to get some real work" :)
>
>> > OK, but why isn't your army of volunteers fixing them?
>
>> They don't know about them, or they don't have the hardware to test?
>> Seriously, let the kernel-janitor's project know about any issues you
>> have and they will be glad to jump on it.  Those people are just
>> chomping a the bit to do something a bit bigger than "compiler warning
>> cleanups" :)
>
> So many times i have seen good ideas brought up, kernel patches being 
> written, posted to lkml, being developed outside mainline for a while and 
> then being forgotten some time later due to lack of energy of some individual 
> to get this into mainline.
>
> If there is an noticeably number of talented programmers (unfortunately, i`m 
> not) , so why not "feeding" them the right way ? Where is those public and 
> transparent and moderated Linux-Kernel "ToDo"- or "Keep an eye on"-list, 
> sorted by priorities, with sort of a "vote for this feature"-button, so those 
> guys have something they can pick up? There is so much great stuff and ideas 
> out there where they could put their work onto or getting involved, it just 
> needs to be found or sort of being "managed" a little bit better.
>
> For myself, i`m waiting for so quite some things to get "one step further", 
> but they are more or less tied to some single individuals, for which you just 
> cannot send some "hey, what`s up with your project"-message every second day. 
> The interest in many nice projects often is quite low and evolution quite 
> slow, but not only because of the fact that they aren`t great, but more 
> because of not getting widely known. It`s not always missing specs, it`s also 
> some missing noise/feedback for different features or missing of some 
> "driving force" to bring things forward. How should one developer know that 
> somebody needs a feature if those who could probably need it don`t request 
> it? Maybe just because of the fact that they even imagine that such feature 
> would be possible ?
>
> Where is those efforts for fixing/integrating fantastic cowloop?
> What about badram/badmem patch ?
> Compressed Ccaching ?
> Somebody helping with development of dm-loop or extend loop.c to support more 
> than 256 devices ?
> Replacement of proprietary, unstable and unelegant vmware-lopp for being able 
> to mount vmware .vmdk files ? Internal Spec for this is open, dm-userspace 
> could be some infrastructure for this, but the author seems to have other 
> priorities
> dm-cow, zfs-fuse - anybody ?
> Kernel based target for AoE (Ata over Ethernet) ?  (there are two independent 
> implementations, but both got stuck at some early experimental stage) 

A quick answer for philosophers:
   <http://www.linuxjournal.com/article/7272>

For example, i don't know if somebody volunteered to be a bug-buddy in
google, see Andrew's 2.6.20-rc6-mm1 announcement. It seems no, as he
still forwards bugzilla reports to developers/maintainers.

I myself am new. But anyway, i can write a little bit of HOWTO

-- effectively handle (among others) LKML, to break free from myths,

-- to not afraid emacs as good editor for issues like symbol-searching (TAGS),
   whitespace, spell (typos) and such,

-- having linux tree up-today with small bandwidth: mirrors, patches, quilt

of course if such things prevent people from participating.

[:(ot) As for Greg's message, imho somebody was bored. There is plenty  ;]
[: of work *in* the kernel, not only in drivers/ related part of it...  ;]

> Just my 2 cents. 

So my.


Greetings.
--
-o--=O`C  info emacs : not found  /. .\ ( is there any reason to live? )
 #oo'L O  info make  : not found  o (yes --- R.I.P. FSF+RMS)
<___=E M  man gcc: not found`-- ( viva Debian Operating System )

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

Re: Free Linux Driver Development!

[devzero]

First off, compliments to this announcement, I liked it very much!

Some comment regarding those "volunteers, waiting to get some real work" :)

> > OK, but why isn't your army of volunteers fixing them?

> They don't know about them, or they don't have the hardware to test?
> Seriously, let the kernel-janitor's project know about any issues you
> have and they will be glad to jump on it.  Those people are just
> chomping a the bit to do something a bit bigger than "compiler warning
> cleanups" :)

So many times i have seen good ideas brought up, kernel patches being written, 
posted to lkml, being developed outside mainline for a while and then being 
forgotten some time later due to lack of energy of some individual to get this 
into mainline.

If there is an noticeably number of talented programmers (unfortunately, i`m 
not) , so why not "feeding" them the right way ? Where is those public and 
transparent and moderated Linux-Kernel "ToDo"- or "Keep an eye on"-list, sorted 
by priorities, with sort of a "vote for this feature"-button, so those guys 
have something they can pick up? There is so much great stuff and ideas out 
there where they could put their work onto or getting involved, it just needs 
to be found or sort of being "managed" a little bit better.

For myself, i`m waiting for so quite some things to get "one step further", but 
they are more or less tied to some single individuals, for which you just 
cannot send some "hey, what`s up with your project"-message every second day. 
The interest in many nice projects often is quite low and evolution quite slow, 
but not only because of the fact that they aren`t great, but more because of 
not getting widely known. It`s not always missing specs, it`s also some missing 
noise/feedback for different features or missing of some "driving force" to 
bring things forward. How should one developer know that somebody needs a 
feature if those who could probably need it don`t request it? Maybe just 
because of the fact that they even imagine that such feature would be possible ?

Where is those efforts for fixing/integrating fantastic cowloop?
What about badram/badmem patch ?
Compressed Ccaching ?
Somebody helping with development of dm-loop or extend loop.c to support more 
than 256 devices ?
Replacement of proprietary, unstable and unelegant vmware-lopp for being able 
to mount vmware .vmdk files ? Internal Spec for this is open, dm-userspace 
could be some infrastructure for this, but the author seems to have other 
priorities
dm-cow, zfs-fuse - anybody ?
Kernel based target for AoE (Ata over Ethernet) ?  (there are two independent 
implementations, but both got stuck at some early experimental stage) 

Just my 2 cents. 

Roland K.
Sysadmin/System Engineer

ps:
This isn`t meant to criticise any of you kernel developers since you`re doing 
fantastic work!


___
Viren-Scan für Ihren PC! Jetzt für jeden. Sofort, online und kostenlos.
Gleich testen! http://www.pc-sicherheit.web.de/freescan/?mc=02

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

Re: Free Linux Driver Development!

[Christer Weinigel]

Greg KH <[EMAIL PROTECTED]> writes:

> Or perhaps your device just needs to add some flow control to it :)

Physical processes are hard to pause. :-)

But yes, adding a 16kByte FIFO before the FT245 would have made life
so much easier for me, but unfortunately the thing that drives the
hardware choice is cost, cost and cost.  

  /Christer

-- 
"Just how much can I get away with and still go to heaven?"

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

Re: Free Linux Driver Development!

[Bill Davidsen]

Jan Engelhardt wrote:

On Jan 31 2007 08:34, David Hollis wrote:

Conversely, I've seen many cases of drivers that are developed by the
community, but kept out-of-kernel forever due to various reasons.  Some
of them are due to the code quality and the developers not accepting the
feedback to get the drivers into shape to be 'kernel worthy', sometimes
it seems to be a lack of interest from the developers to merge upstream.
Maybe because they think they would lose control or something?


Putting the "codingstyle" control aside, often it's because things look
too hackish. Take ipt_ROUTE as an example. It won't get included, since
the "proper" way to do it would be using MARK and iproute2. But many users
don't get that [no criticism here], because ipt_ROUTE is so much easier.
(Probably because iproute2 and other netlink-using tools, like tc, lack
thorough documentation.)

Doing it by MARK a tables and rules is an ugly method, and like anything 
with is spread over many places (the mangle table to MARK), then 'rules' 
and 'tables', spreading an action into many places increases the chances 
of getting parts out of sync and having the whole not work as intended. 
And the 'ip' man page defines everything in BNF, which was hot stuff 
when Algol-60 came out (1960) but which is only readable to people who 
use it frequently.


The ipt_ROUTE allows putting all parts of of the action, from defining 
the set of matching packets to specifying the desired result, the 
routing. And if that changes, it need only change in one place.


Making good administration difficult because it fits some pedantic metal 
model is NOT a good way to decide which features to offer in a kernel.


--
Bill Davidsen <[EMAIL PROTECTED]>
  "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Miguel Ojeda]

On 2/4/07, Greg KH <[EMAIL PROTECTED]> wrote:


Just let me know if you are interested in participating, and what types
of devices you wish to write drivers for (USB, PCI, network, etc.)

thanks,

greg k-h



I would like to participate; however, for people who is not at USA
(say, Europe), are there fair chances to get samples of devices to
work with?

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

Re: Free Linux Driver Development!

[Pierre Ossman]

Hi Greg,

Although I am a bit of a cynic, I really hope that this endeavor works
the way you hope.

I'd also like to offer my services to this quest of yours. If you get
any SD, MMC or SDIO requests, feel free to pass them along to me. I am
not a big fan of debug-by-email though, so I'd prefer vendors who either
can provide samples or where the hardware is cheap and freely available
so I can just go out and by one.

Rgds
-- 
 -- Pierre Ossman

  Linux kernel, MMC maintainerhttp://www.kernel.org
  PulseAudio, core developer  http://pulseaudio.org
  rdesktop, core developer  http://www.rdesktop.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Greg KH]

On Sun, Feb 04, 2007 at 03:04:58AM -0800, Parav Pandit wrote:
> Hi,
> 
> So how can an individual like me having ardor, contribute in Free
> driver development?  What is the eligibility criteria and process for
> contributing in this activity?
> 
> In brief, I come with background of developing, verifying device
> drivers for Linux, Apple MAC OS X, DSP/BIOS RTOS for HBAs, LCD
> controllers, networking L2-L3 ASIC devices, platform management
> drivers, few Samsung SoC peripherals.

Just let me know if you are interested in participating, and what types
of devices you wish to write drivers for (USB, PCI, network, etc.)

thanks,

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

Re: Free Linux Driver Development!

[Greg KH]

On Sun, Feb 04, 2007 at 02:29:13PM +0100, Christer Weinigel wrote:
> Greg KH <[EMAIL PROTECTED]> writes:
> 
> > Why would a userspace driver not work out for this.  We already can
> > saturate the USB bus with a userspace program
> 
> That is unfortunately not quite true.  I have a (unfortunately
> proprietary) driver for a USB device that simply cannot be implemented
> in userspace.  The USB device is a measurement device that pushes
> close to 800 kBytes/second of data through a FT245 chip.  The
> measurement device does no flow control at all, it just presents a
> sample every 125 us to the FT245 and with only 256 bytes of buffer in
> the FT245 the only way to handle that is to have two URBs in flight at
> the same time, and I haven't found any way to do that in a robust and
> non-racey way from userspace.

People do that today just fine with multiple userspace urbs in flight
using usbfs directly.  So it is possible and can be done.

If there are issues with the usbfs code to prevent you from doing this,
please let us know.

Or perhaps your device just needs to add some flow control to it :)

good luck,

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

Re: Free Linux Driver Development!

[Christer Weinigel]

Greg KH <[EMAIL PROTECTED]> writes:

> Why would a userspace driver not work out for this.  We already can
> saturate the USB bus with a userspace program

That is unfortunately not quite true.  I have a (unfortunately
proprietary) driver for a USB device that simply cannot be implemented
in userspace.  The USB device is a measurement device that pushes
close to 800 kBytes/second of data through a FT245 chip.  The
measurement device does no flow control at all, it just presents a
sample every 125 us to the FT245 and with only 256 bytes of buffer in
the FT245 the only way to handle that is to have two URBs in flight at
the same time, and I haven't found any way to do that in a robust and
non-racey way from userspace.  So the comment "The USB subsystem has
changed a lot over time, and it has been possible to create userspace
USB drivers using usbfs/libusb/gadgetfs that operate as fast as the
USB bus allows." from feature-removal-schedule.txt is wrong I
think. :-(

Personally I'd much prefer to release the driver as open source, but
as a consultant you don't get to decide what the customer does.  So
now they sit there with a driver that warns them that it'll stop
working after february 2008.

On a different topic, my personal pet peeve is USB scanners.  There
seems to be just a handful of different manufacturers of chips used in
USB scanners: Realtek and Genesys covers 90% of the scanners.  The
SANE team has done a wonderful job of reverse engineering a lot of
scanners, but the models change so fast that there seems to be no
chance of keeping up.  If the chip manufacturers just released specs
for their chips and the scanner manufacturers could then document what
settings to use Linux could have support for almost all USB scanners
on the market, and it would probably cost them very little to do that.
If I could find a good (4800-9600 dpi) scanner which said "supported
by SANE" on the box I'd buy it immedately.

  /Christer

-- 
"Just how much can I get away with and still go to heaven?"

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

Re: Free Linux Driver Development!

[Michael Buesch]

On Sunday 04 February 2007 07:26, Larry Finger wrote:
> What is true is that none of the OFDM rates work 
> because of some unknown bug, probably in initialization. As a result, we are 
> limited to a maximum
> data rate of 11Mbs, but it is still running in 802.11g mode!

That's also not true for me. I really don't understand why people keep saying
that rates above 11MBit don't work, because they do (and always did) on all
of my 4306 cards.
Sure, rates above 11M don't work for 4318 and similiar, but for those cards
not even 11M works, so one has to use 1M or something.

And there is absolutely no limit to 11MBit in the code.

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

Re: Free Linux Driver Development!

[Michael Buesch]

On Sunday 04 February 2007 07:26, Larry Finger wrote:
 What is true is that none of the OFDM rates work 
 because of some unknown bug, probably in initialization. As a result, we are 
 limited to a maximum
 data rate of 11Mbs, but it is still running in 802.11g mode!

That's also not true for me. I really don't understand why people keep saying
that rates above 11MBit don't work, because they do (and always did) on all
of my 4306 cards.
Sure, rates above 11M don't work for 4318 and similiar, but for those cards
not even 11M works, so one has to use 1M or something.

And there is absolutely no limit to 11MBit in the code.

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

Re: Free Linux Driver Development!

[Christer Weinigel]

Greg KH [EMAIL PROTECTED] writes:

 Why would a userspace driver not work out for this.  We already can
 saturate the USB bus with a userspace program

That is unfortunately not quite true.  I have a (unfortunately
proprietary) driver for a USB device that simply cannot be implemented
in userspace.  The USB device is a measurement device that pushes
close to 800 kBytes/second of data through a FT245 chip.  The
measurement device does no flow control at all, it just presents a
sample every 125 us to the FT245 and with only 256 bytes of buffer in
the FT245 the only way to handle that is to have two URBs in flight at
the same time, and I haven't found any way to do that in a robust and
non-racey way from userspace.  So the comment The USB subsystem has
changed a lot over time, and it has been possible to create userspace
USB drivers using usbfs/libusb/gadgetfs that operate as fast as the
USB bus allows. from feature-removal-schedule.txt is wrong I
think. :-(

Personally I'd much prefer to release the driver as open source, but
as a consultant you don't get to decide what the customer does.  So
now they sit there with a driver that warns them that it'll stop
working after february 2008.

On a different topic, my personal pet peeve is USB scanners.  There
seems to be just a handful of different manufacturers of chips used in
USB scanners: Realtek and Genesys covers 90% of the scanners.  The
SANE team has done a wonderful job of reverse engineering a lot of
scanners, but the models change so fast that there seems to be no
chance of keeping up.  If the chip manufacturers just released specs
for their chips and the scanner manufacturers could then document what
settings to use Linux could have support for almost all USB scanners
on the market, and it would probably cost them very little to do that.
If I could find a good (4800-9600 dpi) scanner which said supported
by SANE on the box I'd buy it immedately.

  /Christer

-- 
Just how much can I get away with and still go to heaven?

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

Re: Free Linux Driver Development!

[Greg KH]

On Sun, Feb 04, 2007 at 02:29:13PM +0100, Christer Weinigel wrote:
 Greg KH [EMAIL PROTECTED] writes:
 
  Why would a userspace driver not work out for this.  We already can
  saturate the USB bus with a userspace program
 
 That is unfortunately not quite true.  I have a (unfortunately
 proprietary) driver for a USB device that simply cannot be implemented
 in userspace.  The USB device is a measurement device that pushes
 close to 800 kBytes/second of data through a FT245 chip.  The
 measurement device does no flow control at all, it just presents a
 sample every 125 us to the FT245 and with only 256 bytes of buffer in
 the FT245 the only way to handle that is to have two URBs in flight at
 the same time, and I haven't found any way to do that in a robust and
 non-racey way from userspace.

People do that today just fine with multiple userspace urbs in flight
using usbfs directly.  So it is possible and can be done.

If there are issues with the usbfs code to prevent you from doing this,
please let us know.

Or perhaps your device just needs to add some flow control to it :)

good luck,

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

Re: Free Linux Driver Development!

[Greg KH]

On Sun, Feb 04, 2007 at 03:04:58AM -0800, Parav Pandit wrote:
 Hi,
 
 So how can an individual like me having ardor, contribute in Free
 driver development?  What is the eligibility criteria and process for
 contributing in this activity?
 
 In brief, I come with background of developing, verifying device
 drivers for Linux, Apple MAC OS X, DSP/BIOS RTOS for HBAs, LCD
 controllers, networking L2-L3 ASIC devices, platform management
 drivers, few Samsung SoC peripherals.

Just let me know if you are interested in participating, and what types
of devices you wish to write drivers for (USB, PCI, network, etc.)

thanks,

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

Re: Free Linux Driver Development!

[Pierre Ossman]

Hi Greg,

Although I am a bit of a cynic, I really hope that this endeavor works
the way you hope.

I'd also like to offer my services to this quest of yours. If you get
any SD, MMC or SDIO requests, feel free to pass them along to me. I am
not a big fan of debug-by-email though, so I'd prefer vendors who either
can provide samples or where the hardware is cheap and freely available
so I can just go out and by one.

Rgds
-- 
 -- Pierre Ossman

  Linux kernel, MMC maintainerhttp://www.kernel.org
  PulseAudio, core developer  http://pulseaudio.org
  rdesktop, core developer  http://www.rdesktop.org
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Miguel Ojeda]

On 2/4/07, Greg KH [EMAIL PROTECTED] wrote:


Just let me know if you are interested in participating, and what types
of devices you wish to write drivers for (USB, PCI, network, etc.)

thanks,

greg k-h



I would like to participate; however, for people who is not at USA
(say, Europe), are there fair chances to get samples of devices to
work with?

--
Miguel Ojeda
http://maxextreme.googlepages.com/index.htm
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Bill Davidsen]

Jan Engelhardt wrote:

On Jan 31 2007 08:34, David Hollis wrote:

Conversely, I've seen many cases of drivers that are developed by the
community, but kept out-of-kernel forever due to various reasons.  Some
of them are due to the code quality and the developers not accepting the
feedback to get the drivers into shape to be 'kernel worthy', sometimes
it seems to be a lack of interest from the developers to merge upstream.
Maybe because they think they would lose control or something?


Putting the codingstyle control aside, often it's because things look
too hackish. Take ipt_ROUTE as an example. It won't get included, since
the proper way to do it would be using MARK and iproute2. But many users
don't get that [no criticism here], because ipt_ROUTE is so much easier.
(Probably because iproute2 and other netlink-using tools, like tc, lack
thorough documentation.)

Doing it by MARK a tables and rules is an ugly method, and like anything 
with is spread over many places (the mangle table to MARK), then 'rules' 
and 'tables', spreading an action into many places increases the chances 
of getting parts out of sync and having the whole not work as intended. 
And the 'ip' man page defines everything in BNF, which was hot stuff 
when Algol-60 came out (1960) but which is only readable to people who 
use it frequently.


The ipt_ROUTE allows putting all parts of of the action, from defining 
the set of matching packets to specifying the desired result, the 
routing. And if that changes, it need only change in one place.


Making good administration difficult because it fits some pedantic metal 
model is NOT a good way to decide which features to offer in a kernel.


--
Bill Davidsen [EMAIL PROTECTED]
  We have more to fear from the bungling of the incompetent than from
the machinations of the wicked.  - from Slashdot
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Christer Weinigel]

Greg KH [EMAIL PROTECTED] writes:

 Or perhaps your device just needs to add some flow control to it :)

Physical processes are hard to pause. :-)

But yes, adding a 16kByte FIFO before the FT245 would have made life
so much easier for me, but unfortunately the thing that drives the
hardware choice is cost, cost and cost.  

  /Christer

-- 
Just how much can I get away with and still go to heaven?

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

Re: Free Linux Driver Development!

[devzero]

First off, compliments to this announcement, I liked it very much!

Some comment regarding those volunteers, waiting to get some real work :)

  OK, but why isn't your army of volunteers fixing them?

 They don't know about them, or they don't have the hardware to test?
 Seriously, let the kernel-janitor's project know about any issues you
 have and they will be glad to jump on it.  Those people are just
 chomping a the bit to do something a bit bigger than compiler warning
 cleanups :)

So many times i have seen good ideas brought up, kernel patches being written, 
posted to lkml, being developed outside mainline for a while and then being 
forgotten some time later due to lack of energy of some individual to get this 
into mainline.

If there is an noticeably number of talented programmers (unfortunately, i`m 
not) , so why not feeding them the right way ? Where is those public and 
transparent and moderated Linux-Kernel ToDo- or Keep an eye on-list, sorted 
by priorities, with sort of a vote for this feature-button, so those guys 
have something they can pick up? There is so much great stuff and ideas out 
there where they could put their work onto or getting involved, it just needs 
to be found or sort of being managed a little bit better.

For myself, i`m waiting for so quite some things to get one step further, but 
they are more or less tied to some single individuals, for which you just 
cannot send some hey, what`s up with your project-message every second day. 
The interest in many nice projects often is quite low and evolution quite slow, 
but not only because of the fact that they aren`t great, but more because of 
not getting widely known. It`s not always missing specs, it`s also some missing 
noise/feedback for different features or missing of some driving force to 
bring things forward. How should one developer know that somebody needs a 
feature if those who could probably need it don`t request it? Maybe just 
because of the fact that they even imagine that such feature would be possible ?

Where is those efforts for fixing/integrating fantastic cowloop?
What about badram/badmem patch ?
Compressed Ccaching ?
Somebody helping with development of dm-loop or extend loop.c to support more 
than 256 devices ?
Replacement of proprietary, unstable and unelegant vmware-lopp for being able 
to mount vmware .vmdk files ? Internal Spec for this is open, dm-userspace 
could be some infrastructure for this, but the author seems to have other 
priorities
dm-cow, zfs-fuse - anybody ?
Kernel based target for AoE (Ata over Ethernet) ?  (there are two independent 
implementations, but both got stuck at some early experimental stage) 

Just my 2 cents. 

Roland K.
Sysadmin/System Engineer

ps:
This isn`t meant to criticise any of you kernel developers since you`re doing 
fantastic work!


___
Viren-Scan für Ihren PC! Jetzt für jeden. Sofort, online und kostenlos.
Gleich testen! http://www.pc-sicherheit.web.de/freescan/?mc=02

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

Re: Free Linux Driver Development!

[Oleg Verych]

 From: devzero web.de
 Newsgroups: gmane.linux.kernel
 Subject: Re: Free Linux Driver Development!
 Date: Sun, 04 Feb 2007 22:37:33 +0100
 Organization: http://freemail.web.de/
 Archived-At: http://permalink.gmane.org/gmane.linux.kernel/489586

 First off, compliments to this announcement, I liked it very much!

 Some comment regarding those volunteers, waiting to get some real work :)

  OK, but why isn't your army of volunteers fixing them?

 They don't know about them, or they don't have the hardware to test?
 Seriously, let the kernel-janitor's project know about any issues you
 have and they will be glad to jump on it.  Those people are just
 chomping a the bit to do something a bit bigger than compiler warning
 cleanups :)

 So many times i have seen good ideas brought up, kernel patches being 
 written, posted to lkml, being developed outside mainline for a while and 
 then being forgotten some time later due to lack of energy of some individual 
 to get this into mainline.

 If there is an noticeably number of talented programmers (unfortunately, i`m 
 not) , so why not feeding them the right way ? Where is those public and 
 transparent and moderated Linux-Kernel ToDo- or Keep an eye on-list, 
 sorted by priorities, with sort of a vote for this feature-button, so those 
 guys have something they can pick up? There is so much great stuff and ideas 
 out there where they could put their work onto or getting involved, it just 
 needs to be found or sort of being managed a little bit better.

 For myself, i`m waiting for so quite some things to get one step further, 
 but they are more or less tied to some single individuals, for which you just 
 cannot send some hey, what`s up with your project-message every second day. 
 The interest in many nice projects often is quite low and evolution quite 
 slow, but not only because of the fact that they aren`t great, but more 
 because of not getting widely known. It`s not always missing specs, it`s also 
 some missing noise/feedback for different features or missing of some 
 driving force to bring things forward. How should one developer know that 
 somebody needs a feature if those who could probably need it don`t request 
 it? Maybe just because of the fact that they even imagine that such feature 
 would be possible ?

 Where is those efforts for fixing/integrating fantastic cowloop?
 What about badram/badmem patch ?
 Compressed Ccaching ?
 Somebody helping with development of dm-loop or extend loop.c to support more 
 than 256 devices ?
 Replacement of proprietary, unstable and unelegant vmware-lopp for being able 
 to mount vmware .vmdk files ? Internal Spec for this is open, dm-userspace 
 could be some infrastructure for this, but the author seems to have other 
 priorities
 dm-cow, zfs-fuse - anybody ?
 Kernel based target for AoE (Ata over Ethernet) ?  (there are two independent 
 implementations, but both got stuck at some early experimental stage) 

A quick answer for philosophers:
   http://www.linuxjournal.com/article/7272

For example, i don't know if somebody volunteered to be a bug-buddy in
google, see Andrew's 2.6.20-rc6-mm1 announcement. It seems no, as he
still forwards bugzilla reports to developers/maintainers.

I myself am new. But anyway, i can write a little bit of HOWTO

-- effectively handle (among others) LKML, to break free from myths,

-- to not afraid emacs as good editor for issues like symbol-searching (TAGS),
   whitespace, spell (typos) and such,

-- having linux tree up-today with small bandwidth: mirrors, patches, quilt

of course if such things prevent people from participating.

[:(ot) As for Greg's message, imho somebody was bored. There is plenty  ;]
[: of work *in* the kernel, not only in drivers/ related part of it...  ;]

 Just my 2 cents. 

So my.


Greetings.
--
-o--=O`C  info emacs : not found  /. .\ ( is there any reason to live? )
 #oo'L O  info make  : not found  o (yes --- R.I.P. FSF+RMS)
___=E M  man gcc: not found`-- ( viva Debian Operating System )

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

Re: Free Linux Driver Development!

[Larry Finger]

On Thu, Feb 01, 2007 at 09:45:45PM EST, Lennart Sorensen wrote:
>On Thu, Feb 01, 2007 at 02:59:03PM +0100, Erik Mouw wrote:
>> I can't remember that kind of corruption ever being reported to the
>> bcm43xx-dev mailing list.

I came into this discussion late as I only read LKML in summary form, but I 
feel I need to address
several misconceptions here.

>Well I assumed it messed up the eeprom settings, since we had to go into
>the advanced driver settings and change it from 802.11b only back to
>auto mode and I would think those settings are stored in the eeprom if
>booting a 2.6.18 kernel and loading the bcm43xx driver can cause it to
>stop working, then it has to be an eeprom setting.

As Michael Buesch has explained, bcm43xx only changes the eeprom under very 
controlled circumstances
that never happen accidentally. It is much more likely that your Windows driver 
uses V4 firmware,
whereas bcm43xx uses V3. Without a power-off step to erase the firmware the 
results are likely to be
indeterminate.

>Actually I suppose the other posibility is that you simply have to power
>cycle before booting windows after linux to avoid any left over settings
>in the chip from being a problem. That may be what I did. Given I
>couldn't get the card to connect using the bcm43xx driver anyhow, I
>didn't spend too much time trying (I am fairly sure I set the AP to
>802.11g only though which may have been a problem).

It is _NOT_ true that bcm43xx only works with 802.11b. My AP is set in 
802.11g-only mode and I have
been using bcm43xx with it for nearly a year. What is true is that none of the 
OFDM rates work
because of some unknown bug, probably in initialization. As a result, we are 
limited to a maximum
data rate of 11Mbs, but it is still running in 802.11g mode!

>> You could use a CardBus or USB card.
>
>I just don't like things sticking out that are breakable.
>
>> So are the bcm43xx maintainers.
>
>Excellent. Is the bcm43xx planning to get 802.11g mode working at some
>point? Is broadcom ever going to help out with any specs for their
>hardware or do they still mistakenly believe that end users are not
>their customers? Given the behaviour of broadcom over the years I know
>I don't intend to buy anything with a broadcom chip in it again, which
>means broadcom's behaviour directly means they will get less sales to the
>laptop makers, since some people will actively avoid anything with
>broadcom's hardware in it. :)

I certainly would hope for a even a little cooperation from Broadcom; however, 
it is not easy to
avoid getting their hardware, particularly with laptops. When I recently 
upgraded, my primary aims
were (1) a 14 inch screen  as the native resolution of a larger one makes 
things too small for my
eyes and reduced resolution looks crappy on an LCD, and (2) an AMD 64 X2 
processor to run an x86_64
OS. The kind of wireless card contained within was not an issue, although the 
BCM4311 that I got
turned out to be a benefit as I became the first developer with the hardware 
needed to find and fix
two major outstanding bugs.

While I'm on my soapbox, I want to thank the group that reverse-engineered the 
Broadcom chips and
the group that did the early coding on the driver. Although the current driver 
still has its faults,
the fact that there is a working driver that doesn't hang or crash an SMP 
version of Linux and
offers usable wireless service for such a complicated piece of totally 
undocumented hardware is a
real tribute to those two groups. Thanks guys.

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

Re: Free Linux Driver Development!

[Larry Finger]

On Thu, Feb 01, 2007 at 09:45:45PM EST, Lennart Sorensen wrote:
On Thu, Feb 01, 2007 at 02:59:03PM +0100, Erik Mouw wrote:
 I can't remember that kind of corruption ever being reported to the
 bcm43xx-dev mailing list.

I came into this discussion late as I only read LKML in summary form, but I 
feel I need to address
several misconceptions here.

Well I assumed it messed up the eeprom settings, since we had to go into
the advanced driver settings and change it from 802.11b only back to
auto mode and I would think those settings are stored in the eeprom if
booting a 2.6.18 kernel and loading the bcm43xx driver can cause it to
stop working, then it has to be an eeprom setting.

As Michael Buesch has explained, bcm43xx only changes the eeprom under very 
controlled circumstances
that never happen accidentally. It is much more likely that your Windows driver 
uses V4 firmware,
whereas bcm43xx uses V3. Without a power-off step to erase the firmware the 
results are likely to be
indeterminate.

Actually I suppose the other posibility is that you simply have to power
cycle before booting windows after linux to avoid any left over settings
in the chip from being a problem. That may be what I did. Given I
couldn't get the card to connect using the bcm43xx driver anyhow, I
didn't spend too much time trying (I am fairly sure I set the AP to
802.11g only though which may have been a problem).

It is _NOT_ true that bcm43xx only works with 802.11b. My AP is set in 
802.11g-only mode and I have
been using bcm43xx with it for nearly a year. What is true is that none of the 
OFDM rates work
because of some unknown bug, probably in initialization. As a result, we are 
limited to a maximum
data rate of 11Mbs, but it is still running in 802.11g mode!

 You could use a CardBus or USB card.

I just don't like things sticking out that are breakable.

 So are the bcm43xx maintainers.

Excellent. Is the bcm43xx planning to get 802.11g mode working at some
point? Is broadcom ever going to help out with any specs for their
hardware or do they still mistakenly believe that end users are not
their customers? Given the behaviour of broadcom over the years I know
I don't intend to buy anything with a broadcom chip in it again, which
means broadcom's behaviour directly means they will get less sales to the
laptop makers, since some people will actively avoid anything with
broadcom's hardware in it. :)

I certainly would hope for a even a little cooperation from Broadcom; however, 
it is not easy to
avoid getting their hardware, particularly with laptops. When I recently 
upgraded, my primary aims
were (1) a 14 inch screen  as the native resolution of a larger one makes 
things too small for my
eyes and reduced resolution looks crappy on an LCD, and (2) an AMD 64 X2 
processor to run an x86_64
OS. The kind of wireless card contained within was not an issue, although the 
BCM4311 that I got
turned out to be a benefit as I became the first developer with the hardware 
needed to find and fix
two major outstanding bugs.

While I'm on my soapbox, I want to thank the group that reverse-engineered the 
Broadcom chips and
the group that did the early coding on the driver. Although the current driver 
still has its faults,
the fact that there is a working driver that doesn't hang or crash an SMP 
version of Linux and
offers usable wireless service for such a complicated piece of totally 
undocumented hardware is a
real tribute to those two groups. Thanks guys.

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

Re: [PATCH] lirc: remove backwards compatibility macro obfuscation (Was: Free Linux Driver Development!)

[Jan Dittmer]

Pekka Enberg wrote:

On 2/2/07, Jan Dittmer <[EMAIL PROTECTED]> wrote:

Pekka, it would be better if you could sort out most of the
basic issues with lirc directly with the developers of lirc
and then prepare a complete patch series and post that to
lkml. Incrementally adding one driver after another. Posting
patches to non-existent sources to lkml is pointless. First
create a discussion base, please.


What discussion base? You need to get rid of the cruft anyway and now
you have patch to do that. I am not volunteering to sort out _all_ the
issues.


I really really welcome your efforts - no doubt.

I wanted to express that the patches you posted are simply not
suitable for lkml discussion as there was no full patchset for
lirc for review posted, prior to your patches.

Normal process for new features (and lirc is a new feature so
far lkml is concerned) is like (as I understand it):
 1. post full patchset
 2. duck
 3. receive criticism & patches
 4. integrate results from 3
 5. goto 1
You started at 3. It would be better to start with the whole
picture at 1.

I hope I made myself clearer now.

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

Re: [PATCH] lirc: remove backwards compatibility macro obfuscation (Was: Free Linux Driver Development!)

[Pekka Enberg]

On 2/2/07, Jan Dittmer <[EMAIL PROTECTED]> wrote:

Pekka, it would be better if you could sort out most of the
basic issues with lirc directly with the developers of lirc
and then prepare a complete patch series and post that to
lkml. Incrementally adding one driver after another. Posting
patches to non-existent sources to lkml is pointless. First
create a discussion base, please.


What discussion base? You need to get rid of the cruft anyway and now
you have patch to do that. I am not volunteering to sort out _all_ the
issues.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] lirc: remove backwards compatibility macro obfuscation (Was: Free Linux Driver Development!)

[Jan Dittmer]

Pekka J Enberg wrote:

From: Pekka Enberg <[EMAIL PROTECTED]>

On 02 Feb 2007 05:54:00 +0100, Christoph Bartelmus <[EMAIL PROTECTED]> wrote:

I just made clear that I don't have the time to do the merging of LIRC
drivers to the kernel myself. In fact a lot of work still needs to be
done before LIRC drivers are ready to be included into the kernel.


[snip]

On 02 Feb 2007 05:54:00 +0100, Christoph Bartelmus <[EMAIL PROTECTED]> wrote:

Any help welcome.


Here's a start. You really should run Lindent on the sources too.


Pekka, it would be better if you could sort out most of the
basic issues with lirc directly with the developers of lirc
and then prepare a complete patch series and post that to
lkml. Incrementally adding one driver after another. Posting
patches to non-existent sources to lkml is pointless. First
create a discussion base, please.


Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]>
---

 drivers/lirc_atiusb/lirc_atiusb.c   |  102 -
 drivers/lirc_bt829/lirc_bt829.c |9 -


You might want to fix the directory structure first and check
which drivers already exist in-tree.
Also, as Vincent noted, most drivers have to be converted
to use the input layer first.

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

Re: [PATCH] lirc: remove backwards compatibility macro obfuscation (Was: Free Linux Driver Development!)

[Vincent Vanackere]

On 2/2/07, Pekka J Enberg <[EMAIL PROTECTED]> wrote:

From: Pekka Enberg <[EMAIL PROTECTED]>
 [...]
 drivers/lirc_atiusb/lirc_atiusb.c   |  102 -

 ^^

I may be mistaken, but the lirc_atiusb module looks redondant with
the driver already in drivers/usb/input/ati_remote.c.
Moreover, I was under the impression that the input layer was
currently considered the "right way" to implement the kernel side lirc
needs (AFAICT the lircd daemon is already able to handle events from
the input layer).

So I'm wondering : in view of a kernel merge, wouldn't it be better
for the lirc drivers to be ported to the input layer (linux-input ML
in cc:) ?

Regards,

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

Re: [PATCH] lirc: remove backwards compatibility macro obfuscation (Was: Free Linux Driver Development!)

[Vincent Vanackere]

On 2/2/07, Pekka J Enberg [EMAIL PROTECTED] wrote:

From: Pekka Enberg [EMAIL PROTECTED]
 [...]
 drivers/lirc_atiusb/lirc_atiusb.c   |  102 -

 ^^

I may be mistaken, but the lirc_atiusb module looks redondant with
the driver already in drivers/usb/input/ati_remote.c.
Moreover, I was under the impression that the input layer was
currently considered the right way to implement the kernel side lirc
needs (AFAICT the lircd daemon is already able to handle events from
the input layer).

So I'm wondering : in view of a kernel merge, wouldn't it be better
for the lirc drivers to be ported to the input layer (linux-input ML
in cc:) ?

Regards,

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

Re: [PATCH] lirc: remove backwards compatibility macro obfuscation (Was: Free Linux Driver Development!)

[Jan Dittmer]

Pekka J Enberg wrote:

From: Pekka Enberg [EMAIL PROTECTED]

On 02 Feb 2007 05:54:00 +0100, Christoph Bartelmus [EMAIL PROTECTED] wrote:

I just made clear that I don't have the time to do the merging of LIRC
drivers to the kernel myself. In fact a lot of work still needs to be
done before LIRC drivers are ready to be included into the kernel.


[snip]

On 02 Feb 2007 05:54:00 +0100, Christoph Bartelmus [EMAIL PROTECTED] wrote:

Any help welcome.


Here's a start. You really should run Lindent on the sources too.


Pekka, it would be better if you could sort out most of the
basic issues with lirc directly with the developers of lirc
and then prepare a complete patch series and post that to
lkml. Incrementally adding one driver after another. Posting
patches to non-existent sources to lkml is pointless. First
create a discussion base, please.


Signed-off-by: Pekka Enberg [EMAIL PROTECTED]
---

 drivers/lirc_atiusb/lirc_atiusb.c   |  102 -
 drivers/lirc_bt829/lirc_bt829.c |9 -


You might want to fix the directory structure first and check
which drivers already exist in-tree.
Also, as Vincent noted, most drivers have to be converted
to use the input layer first.

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

Re: [PATCH] lirc: remove backwards compatibility macro obfuscation (Was: Free Linux Driver Development!)

[Pekka Enberg]

On 2/2/07, Jan Dittmer [EMAIL PROTECTED] wrote:

Pekka, it would be better if you could sort out most of the
basic issues with lirc directly with the developers of lirc
and then prepare a complete patch series and post that to
lkml. Incrementally adding one driver after another. Posting
patches to non-existent sources to lkml is pointless. First
create a discussion base, please.


What discussion base? You need to get rid of the cruft anyway and now
you have patch to do that. I am not volunteering to sort out _all_ the
issues.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] lirc: remove backwards compatibility macro obfuscation (Was: Free Linux Driver Development!)

[Jan Dittmer]

Pekka Enberg wrote:

On 2/2/07, Jan Dittmer [EMAIL PROTECTED] wrote:

Pekka, it would be better if you could sort out most of the
basic issues with lirc directly with the developers of lirc
and then prepare a complete patch series and post that to
lkml. Incrementally adding one driver after another. Posting
patches to non-existent sources to lkml is pointless. First
create a discussion base, please.


What discussion base? You need to get rid of the cruft anyway and now
you have patch to do that. I am not volunteering to sort out _all_ the
issues.


I really really welcome your efforts - no doubt.

I wanted to express that the patches you posted are simply not
suitable for lkml discussion as there was no full patchset for
lirc for review posted, prior to your patches.

Normal process for new features (and lirc is a new feature so
far lkml is concerned) is like (as I understand it):
 1. post full patchset
 2. duck
 3. receive criticism  patches
 4. integrate results from 3
 5. goto 1
You started at 3. It would be better to start with the whole
picture at 1.

I hope I made myself clearer now.

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

Re: Free Linux Driver Development!

[Christoph Bartelmus]

On Wed, 31 Jan 2007 21:20:06 +0100 Greg KH wrote:

> On Wed, Jan 31, 2007 at 02:06:32PM +0100, Nicolas Mailhot wrote:
>> I'd really love if the same offer was extended to GPL out-of-tree
>> driver trees.
>
> This kind of offer has _always_ been there for out-of-tree GPL
> drivers. I have contacted many different groups and driver authors
> over the years to offer my help in trying to get their code into the
> mainline kernel.
>
> Some take me up on the offer, others ignore it, and still others
> activly refuse to do so, saying they want to stay out-of-the tree
> (lirc is one of these examples...)

I'm the LIRC maintainer. I don't know what let's you think LIRC wants to  
stay out-of-the-tree.

I just made clear that I don't have the time to do the merging of LIRC  
drivers to the kernel myself. In fact a lot of work still needs to be  
done before LIRC drivers are ready to be included into the kernel.  
Spreading the impression that LIRC refuses to work with kernel  
developers is not particularly helpful...

Any help welcome.

Christoph

Pls Cc me on replies, I'm not subscribed.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Erik Mouw]

On Thu, Feb 01, 2007 at 09:45:06AM -0500, Lennart Sorensen wrote:
> On Thu, Feb 01, 2007 at 02:59:03PM +0100, Erik Mouw wrote:
> > I can't remember that kind of corruption ever being reported to the
> > bcm43xx-dev mailing list.
> 
> Well I assumed it messed up the eeprom settings, since we had to go into
> the advanced driver settings and change it from 802.11b only back to
> auto mode and I would think those settings are stored in the eeprom if
> booting a 2.6.18 kernel and loading the bcm43xx driver can cause it to
> stop working, then it has to be an eeprom setting.
> 
> Actually I suppose the other posibility is that you simply have to power
> cycle before booting windows after linux to avoid any left over settings
> in the chip from being a problem.  That may be what I did.  Given I
> couldn't get the card to connect using the bcm43xx driver anyhow, I
> didn't spend too much time trying (I am fairly sure I set the AP to
> 802.11g only though which may have been a problem).

That's what my laptop needs. Not for the wireless card, but somehow
windows locks up if I just reboot the machine. Of course no nice Oops
message or so.

> Excellent.  Is the bcm43xx planning to get 802.11g mode working at some
> point?

Most certainly, the plans are there for quite some time, but...

>  Is broadcom ever going to help out with any specs for their
> hardware or do they still mistakenly believe that end users are not
> their customers?

... the documentation isn't. Right now the only available documentation
comes from reverse engineering. It's actually rather amazing that the
authors came this far, no vendor documentation yet still a lot of
supported cards.

>  Given the behaviour of broadcom over the years I know
> I don't intend to buy anything with a broadcom chip in it again, which
> means broadcom's behaviour directly means they will get less sales to the
> laptop makers, since some people will actively avoid anything with
> broadcom's hardware in it. :)

That's my take as well. They already lost us on the Gig ethernet cards.
A couple of years ago we considered Broadcom based cards, but given the
lack of vendor driver support, we got Intel E1000 based cards instead.
We also considered NatSemi gigE cards, but the Intels were much faster.
Right now we use about 15 E1000's with probably more to come (they go
in every new machine). Not a high figure but still a lost sale for
Broadcom.

As for wireless, for personal use I needed a wireless PCMCIA/CardBus
card and a Linksys bcm4318 based card was the only reasonably supported
card I could get. It works but still has its peculiarities.


Erik

-- 
+-- Erik Mouw -- www.harddisk-recovery.nl -- 0800 220 20 20 --
| Eigen lab: Delftechpark 26, 2628 XH, Delft, Nederland
| Files foetsie, bestanden kwijt, alle data weg?!
| Blijf kalm en neem contact op met Harddisk-recovery.nl!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Michael K. Edwards]

On 2/1/07, Lennart Sorensen <[EMAIL PROTECTED]> wrote:

Sometimes I might be.  At least on the days I have to deal with problems
in Windows (it's not even my machine, so I don't get to pick what it
runs all the time. :)  I haven't had particularly much luck getting a
stable wireless going on linux yet, although I haven't put much effort
into it yet either.  I figure in a couple of years there will be so many
wifi devices around that wireless won't work anymore anyhow so it isn't
a high priority.  I like simple trustworthy wires.


For what it's worth, hostap + Prism chips of various kinds has worked
quite solidly for 7-8 years or so, and I shipped handheld products
with it in 2001 or so and ran all of my wireless infrastructure gear
on it until I switched to off-the-shelf Broadcom- and Atheros-based
gear a couple of years ago (running OpenWRT and variants thereof).
The apparent inability of any wireless vendor to fix a low-level
firmware bug without breaking at least one common order of operations
in the driver API is hardly Linux's fault.

As it stands, there's enough of a learning and fiddling curve with
every WiFi driver that it's usually not very time-efficient to get
WiFi working under Linux on any single box that shipped with Windows.
But given a controlled configuration and some up-front time
investment, it's not that hard to switch over your local environment
(my neighbors and I have a WDS mesh set up), at which point you may be
the only people within RF range whose WiFi doesn't go belly-up when
some mangled frame comes along.  In this case, it's the last 20% of
the effort that produces 80% of the value.  (Bye-bye, telco monopoly;
the only live wires remaining into our house are the AC mains.)

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

Re: QUATECH driver (was Free Linux Driver Development!)

[Sergei Organov]

Alan <[EMAIL PROTECTED]> writes:
>> 3. Vendor driver is rather close to the generic one being in the kernel,
>>so maybe it's better to improve generic one instead of adding yet
>>another driver to the tree.
>
> Firstly can you post a patch which adds the relevant identifiers to the
> current pcmcia serial driver so that 115,200 works but nothing higher.

OK, I'll try to recover what I did (as I've dropped the change after I
saw it can't do 460,800), and submit the patch.

> After that I'd like to take a look at the needed changes for higher speed
> support using the 2.6.20-mm work which adds arbitary speed support.

I expect it'll be rather hard for me to test the changes then, as my IBM
ThinkPad T43 suffers from kernel IDE/SATA/PATA issues, and running every
new kernel was a big pain so far (it currently runs 2.6.16.8) :(

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

Re: Rewriting floppy.c was Re: Free Linux Driver Development!

[Al Viro]

On Thu, Feb 01, 2007 at 02:12:22PM +0100, Bartlomiej Zolnierkiewicz wrote:
> On 31 Jan 2007 11:08:14 +0100, Andi Kleen <[EMAIL PROTECTED]> wrote:
> >Greg KH <[EMAIL PROTECTED]> writes:
> >>
> >> What?  Throw a fresh-faced newbie instantly into the tar-pit of despair
> >> that floppy.c is?  Do you want everyone just to run screaming from
> >> kernel development never to be seen again?
> 
> floppy.c is not really that ugly or complicated...
> 
> It just needs some care:
> 
> * cleanup of the over-usage of macros (DP macro etc)
> * DocBook documentation would be nice
> * make debugging printks optional by using macros in a smart way
>  (see libata code for examples)
> * tracking and fixing current regressions
 
* piece of shit FSM buried in various continuation methods.
* one hell of a problem with regression testing.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Lennart Sorensen]

On Thu, Feb 01, 2007 at 04:46:38PM +0100, Michael Buesch wrote:
> Nah, why do you think it will screw up the eeprom?
> Did you try to completely power off the machine before rebooting
> into windows?

No at the time I don't think I powered it off, and I suspect that is
probably what went wrong.  The windows driver probably didn't like the
state of the chip after linux had poked it.

> I _really_ _really_ _really_ think that there is no chance of writing
> the eeprom by accident. It is protected by some write-enable bit in
> PCI config space. There is only one place where we enable that bit
> and where we actually _write_ to the eeprom shadow mmio space. That's
> the eeprom writing code. It will output _lots_ of kernelmessages that
> you really can't miss when that happens. And it's only called on behalf
> of a private ioctl user request. _And_ it verifies the data with a CRC
> check. So you really can't call it by accident.

Well it must have just been the state of some registers then.

> But prove me wrong and show the code that writes to eeprom. :)

I suspect I can't.  I still can't make it connect successfully to
anything yet, but that could just be a configuration problem, or it not
liking WPA encryption yet.

> Are you suggesting that bcm43xx people don't, or what?

I have just mainly seen messages about devicescape from the ralink
driver.

> Are you living on another planet than me? Mine is called "Earth".

Sometimes I might be.  At least on the days I have to deal with problems
in Windows (it's not even my machine, so I don't get to pick what it
runs all the time. :)  I haven't had particularly much luck getting a
stable wireless going on linux yet, although I haven't put much effort
into it yet either.  I figure in a couple of years there will be so many
wifi devices around that wireless won't work anymore anyhow so it isn't
a high priority.  I like simple trustworthy wires.

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

Re: Free Linux Driver Development!

[Michael Buesch]

On Tuesday 30 January 2007 23:23, Lennart Sorensen wrote:
> On Tue, Jan 30, 2007 at 05:12:31PM -0500, Jeff Garzik wrote:
> > You mean the bcm43xx wireless driver that's been upstream for months?
> 
> And seems to do 802.11b only and screw up the eeprom settings so that
> the windows driver gets confused next time you boot windows.  Lovely

Nah, why do you think it will screw up the eeprom?
Did you try to completely power off the machine before rebooting
into windows?

I _really_ _really_ _really_ think that there is no chance of writing
the eeprom by accident. It is protected by some write-enable bit in
PCI config space. There is only one place where we enable that bit
and where we actually _write_ to the eeprom shadow mmio space. That's
the eeprom writing code. It will output _lots_ of kernelmessages that
you really can't miss when that happens. And it's only called on behalf
of a private ioctl user request. _And_ it verifies the data with a CRC
check. So you really can't call it by accident.

But prove me wrong and show the code that writes to eeprom. :)

> driver.  If the bios on the laptop in question would let me change the
> minipci card I would.  To something with a ralink on it.
> 
> Seems the ralink driver maintainers are doing a lot of the work on the
> core wifi infastructure too.  Lots of work beyond just the driver then.

Are you suggesting that bcm43xx people don't, or what?
Are you living on another planet than me? Mine is called "Earth".

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

Re: Free Linux Driver Development!

[Lennart Sorensen]

On Thu, Feb 01, 2007 at 02:59:03PM +0100, Erik Mouw wrote:
> I can't remember that kind of corruption ever being reported to the
> bcm43xx-dev mailing list.

Well I assumed it messed up the eeprom settings, since we had to go into
the advanced driver settings and change it from 802.11b only back to
auto mode and I would think those settings are stored in the eeprom if
booting a 2.6.18 kernel and loading the bcm43xx driver can cause it to
stop working, then it has to be an eeprom setting.

Actually I suppose the other posibility is that you simply have to power
cycle before booting windows after linux to avoid any left over settings
in the chip from being a problem.  That may be what I did.  Given I
couldn't get the card to connect using the bcm43xx driver anyhow, I
didn't spend too much time trying (I am fairly sure I set the AP to
802.11g only though which may have been a problem).

> You could use a CardBus or USB card.

I just don't like things sticking out that are breakable.

> So are the bcm43xx maintainers.

Excellent.  Is the bcm43xx planning to get 802.11g mode working at some
point?  Is broadcom ever going to help out with any specs for their
hardware or do they still mistakenly believe that end users are not
their customers?  Given the behaviour of broadcom over the years I know
I don't intend to buy anything with a broadcom chip in it again, which
means broadcom's behaviour directly means they will get less sales to the
laptop makers, since some people will actively avoid anything with
broadcom's hardware in it. :)

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

Re: Free Linux Driver Development!

[Alan]

> 3. Vendor driver is rather close to the generic one being in the kernel,
>so maybe it's better to improve generic one instead of adding yet
>another driver to the tree.

Firstly can you post a patch which adds the relevant identifiers to the
current pcmcia serial driver so that 115,200 works but nothing higher.
After that I'd like to take a look at the needed changes for higher speed
support using the 2.6.20-mm work which adds arbitary speed support.

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

Re: Free Linux Driver Development!

[Sergei Organov]

Greg KH <[EMAIL PROTECTED]> writes:

> On Wed, Jan 31, 2007 at 08:41:03PM +0300, Sergei Organov wrote:
>> Greg KH <[EMAIL PROTECTED]> writes:
>> [...]
>> >> And there are plenty of documented devices that no one cares enough
>> >> about to submit a driver for.
>> >
>> > Any specific examples?  I have a long list of people who wish to write
>> > new drivers but just don't know which hardware is not yet supported.
>> 
>> Maybe not entirely a new driver, as there already exist out-of-kernel
>> vendor GPL driver, but if somebody is willing to resolve the issue
>> described here:
>> 
>> 
>> 
>> please contact me, and I'll be willing to help in testing as I have the
>> hardware.
>
> Do you have a pointer to the driver source anywhere?

Sure, here it is:



> I suggest just posting it as a patch to the tree as documented in
> Documentation/SubmittingPatches and seeing how that goes.

That won't go, I'm afraid:

1. Vendor driver doesn't compile for recent kernels. I did compile it,
   but using brute-force approach that is not appropriate for the
   kernel.

2. There is generic driver in the kernel that supports this card among
   others, should I add the ID of this particular card, but doesn't
   support baud rates higher than 115200.

3. Vendor driver is rather close to the generic one being in the kernel,
   so maybe it's better to improve generic one instead of adding yet
   another driver to the tree.

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