TODO list

TODO list

[James Courtier-Dutton]

Hi,

I was wondering what the current TODO list is for ALSA. The current one 
in alsa-driver hg seems somewhat out of date.
My list has the following, in no particular order:
1) Finish reverse engineering some sound cards (e.g. Creative EMU1212M)
2) Implement needed features on some already reverse engineered cards. 
e.g. The Creative Audigy PCMCIA.
3) Add dB gain architecture.
4) Improve dmix, specifically for 44.1 kHz and games like Doom3. Perhaps 
using the system clock, adjusted to match the sound card hardware clock, 
to provide accurate sample timing, at multiple different sample rates, 
irrespective of the rate the sound card runs at.
5) Perhaps use the system clock to help resample so that user space sees 
a single sample rate clock, but let alsa-lib automatically adjust for 
the different clocks of different sound cards.
6) Think of some way to simplify the mixer interface for user space 
mixers. Surely, it does not have to be so complex as it currently is?
7) Provide better OSS emulation support. E.g. redirect all access to 
/dev/dsp into user space so it can use all the features of alsa-lib 
without needing aoss. (aoss does not work if the application uses 
dynamically linked audio driver plugins.






-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642

Re: TODO list

[Lee Revell]

On Thu, 2006-05-25 at 19:10 +0100, James Courtier-Dutton wrote:
> 7) Provide better OSS emulation support. E.g. redirect all access to 
> /dev/dsp into user space so it can use all the features of alsa-lib 
> without needing aoss. (aoss does not work if the application uses 
> dynamically linked audio driver plugins.
> 

What mechanisms does the kernel provide that could help with this?

Lee



-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642

Re: TODO list

[Takashi Iwai]

At Thu, 25 May 2006 19:10:30 +0100,
James Courtier-Dutton wrote:
> 
> Hi,
> 
> I was wondering what the current TODO list is for ALSA. The current one 
> in alsa-driver hg seems somewhat out of date.

Yep.  Some documents in alsa-driver tree are obsoleted.  Perhaps
better to remove them.

> My list has the following, in no particular order:
> 1) Finish reverse engineering some sound cards (e.g. Creative EMU1212M)
> 2) Implement needed features on some already reverse engineered cards. 
> e.g. The Creative Audigy PCMCIA.
> 3) Add dB gain architecture.
> 4) Improve dmix, specifically for 44.1 kHz and games like Doom3.

Actually, it's not dmix but rate plugin that causes more problems...

> Perhaps 
> using the system clock, adjusted to match the sound card hardware clock, 
> to provide accurate sample timing, at multiple different sample rates, 
> irrespective of the rate the sound card runs at.
> 5) Perhaps use the system clock to help resample so that user space sees 
> a single sample rate clock, but let alsa-lib automatically adjust for 
> the different clocks of different sound cards.
> 6) Think of some way to simplify the mixer interface for user space 
> mixers. Surely, it does not have to be so complex as it currently is?
> 7) Provide better OSS emulation support. E.g. redirect all access to 
> /dev/dsp into user space so it can use all the features of alsa-lib 
> without needing aoss. (aoss does not work if the application uses 
> dynamically linked audio driver plugins.

A dummy kernel driver just to translate syscalls to communication with
a user daemon is the only possible workaround, IMO.  This idea was
denied once quite ago, but I don't see any other good way right now.


My additional wishes are:

8) Improve release engineering.

9) Better organized Web pages and BTS.

10) Build standard test suite and diagnosis tools.


Takashi

Re: TODO list

[James Courtier-Dutton]

Takashi Iwai wrote:
>> 7) Provide better OSS emulation support. E.g. redirect all access to 
>> /dev/dsp into user space so it can use all the features of alsa-lib 
>> without needing aoss. (aoss does not work if the application uses 
>> dynamically linked audio driver plugins.
>>     
>
> A dummy kernel driver just to translate syscalls to communication with
> a user daemon is the only possible workaround, IMO.  This idea was
> denied once quite ago, but I don't see any other good way right now.
>   
That is my thought as well. When I looked into the idea some time ago, I 
concluded that is would be a rather large project, so I did not proceed 
as I have other more important (for me) ALSA features.
Can a user space daemon create /dev files, so that the application calls 
never actually reach kernel space?
If we can create such a pipe, that can forward 
open/close/read/write/ioctl, that should be enough. We then have to 
think about shared memory to look like DMA space to the application 
using us.

>
> My additional wishes are:
>
> 8) Improve release engineering.
>
> 9) Better organized Web pages and BTS.
>
> 10) Build standard test suite and diagnosis tools.
>
>   
The words "Under staffed" comes to mind. :-)
> Takashi
>   

James

Re: TODO list

[Takashi Iwai]

At Fri, 26 May 2006 12:29:11 +0100,
James Courtier-Dutton wrote:
> 
> Takashi Iwai wrote:
> >> 7) Provide better OSS emulation support. E.g. redirect all access to 
> >> /dev/dsp into user space so it can use all the features of alsa-lib 
> >> without needing aoss. (aoss does not work if the application uses 
> >> dynamically linked audio driver plugins.
> >>     
> >
> > A dummy kernel driver just to translate syscalls to communication with
> > a user daemon is the only possible workaround, IMO.  This idea was
> > denied once quite ago, but I don't see any other good way right now.
> >   
> That is my thought as well. When I looked into the idea some time ago, I 
> concluded that is would be a rather large project, so I did not proceed 
> as I have other more important (for me) ALSA features.
> Can a user space daemon create /dev files, so that the application calls 
> never actually reach kernel space?

No, only the kernel driver can handle certain syscalls like ioctl and
mmap properly.  So, it must be a kernel driver that communicated with
OSS apps (unless using LD_PRELOAD hack).

The driver interprets each syscall to a certain protocol communicated
with a dedicated daemon, and the daemon interprets it again to the
real ALSA access.

> If we can create such a pipe, that can forward 
> open/close/read/write/ioctl, that should be enough. We then have to 
> think about shared memory to look like DMA space to the application 
> using us.

mmap would be still tricky, maybe a kind of emulation via read/write.


Takashi

Re: TODO list

[James Courtier-Dutton]

Takashi Iwai wrote:
> At Fri, 26 May 2006 12:29:11 +0100,
> James Courtier-Dutton wrote:
>   
>> Takashi Iwai wrote:
>>     
>>>> 7) Provide better OSS emulation support. E.g. redirect all access to 
>>>> /dev/dsp into user space so it can use all the features of alsa-lib 
>>>> without needing aoss. (aoss does not work if the application uses 
>>>> dynamically linked audio driver plugins.
>>>>     
>>>>         
>>> A dummy kernel driver just to translate syscalls to communication with
>>> a user daemon is the only possible workaround, IMO.  This idea was
>>> denied once quite ago, but I don't see any other good way right now.
>>>   
>>>       
>> That is my thought as well. When I looked into the idea some time ago, I 
>> concluded that is would be a rather large project, so I did not proceed 
>> as I have other more important (for me) ALSA features.
>> Can a user space daemon create /dev files, so that the application calls 
>> never actually reach kernel space?
>>     
>
> No, only the kernel driver can handle certain syscalls like ioctl and
> mmap properly.  So, it must be a kernel driver that communicated with
> OSS apps (unless using LD_PRELOAD hack).
>
> The driver interprets each syscall to a certain protocol communicated
> with a dedicated daemon, and the daemon interprets it again to the
> real ALSA access.
>
>   
>> If we can create such a pipe, that can forward 
>> open/close/read/write/ioctl, that should be enough. We then have to 
>> think about shared memory to look like DMA space to the application 
>> using us.
>>     
>
> mmap would be still tricky, maybe a kind of emulation via read/write.
>
>
> Takashi
>   

For mmap, all that happens is that the application asks for a mmap 
address from the kernel.
If we could get the kernel to manipulate shared memory, so that the mmap 
address given to the application is shared with the daemon, surely that 
would work.
Unfortunately, this might require some kernel memory manager modifications.
Shall I ask about this on the kernel mm list?

James

Re: TODO list

[Takashi Iwai]

At Fri, 26 May 2006 17:33:39 +0100,
James Courtier-Dutton wrote:
> 
> Takashi Iwai wrote:
> > At Fri, 26 May 2006 12:29:11 +0100,
> > James Courtier-Dutton wrote:
> >   
> >> Takashi Iwai wrote:
> >>     
> >>>> 7) Provide better OSS emulation support. E.g. redirect all access to 
> >>>> /dev/dsp into user space so it can use all the features of alsa-lib 
> >>>> without needing aoss. (aoss does not work if the application uses 
> >>>> dynamically linked audio driver plugins.
> >>>>     
> >>>>         
> >>> A dummy kernel driver just to translate syscalls to communication with
> >>> a user daemon is the only possible workaround, IMO.  This idea was
> >>> denied once quite ago, but I don't see any other good way right now.
> >>>   
> >>>       
> >> That is my thought as well. When I looked into the idea some time ago, I 
> >> concluded that is would be a rather large project, so I did not proceed 
> >> as I have other more important (for me) ALSA features.
> >> Can a user space daemon create /dev files, so that the application calls 
> >> never actually reach kernel space?
> >>     
> >
> > No, only the kernel driver can handle certain syscalls like ioctl and
> > mmap properly.  So, it must be a kernel driver that communicated with
> > OSS apps (unless using LD_PRELOAD hack).
> >
> > The driver interprets each syscall to a certain protocol communicated
> > with a dedicated daemon, and the daemon interprets it again to the
> > real ALSA access.
> >
> >   
> >> If we can create such a pipe, that can forward 
> >> open/close/read/write/ioctl, that should be enough. We then have to 
> >> think about shared memory to look like DMA space to the application 
> >> using us.
> >>     
> >
> > mmap would be still tricky, maybe a kind of emulation via read/write.
> >
> >
> > Takashi
> >   
> 
> For mmap, all that happens is that the application asks for a mmap 
> address from the kernel.
> If we could get the kernel to manipulate shared memory, so that the mmap 
> address given to the application is shared with the daemon, surely that 
> would work.

The sharing of memory between the app and the daemon is easy via a
simple mmap invoked from both sides.  But, sharing the mmapped buffer
from a sound driver between the daemon and the app over yet another
driver is a tough problem, because the buffer is strictly bound to the
sound card hardware.

> Unfortunately, this might require some kernel memory manager modifications.
> Shall I ask about this on the kernel mm list?

I don't think it's worthy at this stage at all.
We need to consider first the basic design more deeply.
For example, even if we get the mmapped buffer, it's not enough for
the whole operation, especially when the period/buffer size doesn't
match with whta OSS requires.


Takashi

Re: TODO list

[James Courtier-Dutton]

Takashi Iwai wrote:
>> For mmap, all that happens is that the application asks for a mmap 
>> address from the kernel.
>> If we could get the kernel to manipulate shared memory, so that the mmap 
>> address given to the application is shared with the daemon, surely that 
>> would work.
>>     
>
> The sharing of memory between the app and the daemon is easy via a
> simple mmap invoked from both sides.  But, sharing the mmapped buffer
> from a sound driver between the daemon and the app over yet another
> driver is a tough problem, because the buffer is strictly bound to the
> sound card hardware.
>   

> We need to consider first the basic design more deeply.
> For example, even if we get the mmapped buffer, it's not enough for
> the whole operation, especially when the period/buffer size doesn't
> match with whta OSS requires.
>
>
> Takashi
>   

I was thinking more along the lines of User App -> OSS kernel shim -> 
userland daemon buffer, one buffer per user app -> alsa-lib.
So, the mmap would not be a real mmap, it would be a simple matter of 
tricking the User app into thinking it is mmapped. It would be a double 
buffer really.
So, the daemon buffer would just be whatever size the OSS user app 
wanted, and the daemon would then pass it's contents to alsa-lib or 
jackd as and when needed.
All this would probably only be possible if some high res timer source 
(e.g. the system timer) was used to trigger the period boundaries. I 
think I mentioned that idea some time ago. Maybe we should just aim for 
that TODO item to help dmix work better at 44100Hz, and then worry about 
the OSS kernel shim after that.
Maybe by that time....OSS would have disappeared! :-)

James

Re: TODO list

[Takashi Iwai]

At Fri, 26 May 2006 18:30:36 +0100,
James Courtier-Dutton wrote:
> 
> Takashi Iwai wrote:
> >> For mmap, all that happens is that the application asks for a mmap 
> >> address from the kernel.
> >> If we could get the kernel to manipulate shared memory, so that the mmap 
> >> address given to the application is shared with the daemon, surely that 
> >> would work.
> >>     
> >
> > The sharing of memory between the app and the daemon is easy via a
> > simple mmap invoked from both sides.  But, sharing the mmapped buffer
> > from a sound driver between the daemon and the app over yet another
> > driver is a tough problem, because the buffer is strictly bound to the
> > sound card hardware.
> >   
> 
> > We need to consider first the basic design more deeply.
> > For example, even if we get the mmapped buffer, it's not enough for
> > the whole operation, especially when the period/buffer size doesn't
> > match with whta OSS requires.
> >
> >
> > Takashi
> >   
> 
> I was thinking more along the lines of User App -> OSS kernel shim -> 
> userland daemon buffer, one buffer per user app -> alsa-lib.
> So, the mmap would not be a real mmap, it would be a simple matter of 
> tricking the User app into thinking it is mmapped. It would be a double 
> buffer really.

Then it's as same as what I thought.  This implementation is pretty
easy.  Let both side call mmap just like POSIX shm does.


Takashi

Re: TODO list

[Johannes Berg]

[-- Attachment #1.1: Type: text/plain, Size: 1660 bytes --]

Hah, finally found the thread. I knew there was something like this
lingering about.

> I was thinking more along the lines of User App -> OSS kernel shim -> 
> userland daemon buffer, one buffer per user app -> alsa-lib.
> So, the mmap would not be a real mmap, it would be a simple matter of 
> tricking the User app into thinking it is mmapped. It would be a double 
> buffer really.
> So, the daemon buffer would just be whatever size the OSS user app 
> wanted, and the daemon would then pass it's contents to alsa-lib or 
> jackd as and when needed.
> All this would probably only be possible if some high res timer source 
> (e.g. the system timer) was used to trigger the period boundaries. I 
> think I mentioned that idea some time ago. Maybe we should just aim for 
> that TODO item to help dmix work better at 44100Hz, and then worry about 
> the OSS kernel shim after that.

I wonder if the kernel 'shim' should really be tied to OSS. I see
another application for this: bluetooth audio. Currently, there's a
kernel plugin that as far as I can tell doesn't do much more than
exactly this, push data it received from one side to the other side, the
actual communication is done in userspace. If we had a generic 'sound
driver' below alsa that could create any card with any mixer (compare to
the uinput layer!) then we could do *all* of that in userspace with
standard means.

And for the OSS emulation it'd just mean re-using that existing
interface and the existing oss emulation code (which moves and is
changed to only apply over virtual devices), and putting all the tricky
stuff into the oss daemon.

johannes

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

[-- Attachment #2: Type: text/plain, Size: 299 bytes --]

Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

TODO list

[José Pekkarinen]

	Hi,

	I'm studying the projects listed in you TODO list to try to address which 
of these projects listed are interesting, what are the status on them, and try 
to prioritize tasks in their scope, to at some point give some contributions 
to the community.

	The targets we have are the following:

	1) Improve the performance of the interrupt handling in kvm.
	2) Improve the communication between virtual machines in the same host.

	I see several task listed here that can fall under these scopes so I want 
to ask if this is the right mailing list, and if it's ok for you to open a 
couple of threads to comment these tasks further and study which are the 
priorities on them.

	Best regards.

	José.

	

todo list

[varun satrawla]

Hi,

I'd like to contribute to some of the TODOs listed on the kvm home page.
Can someone send me the process involved? I would like to contribute
to adding the VTd-2 support. [If someone is already working on it, maybe
I can help out on some specific pieces..]

thanks,
vs

TODO list

[Kulikov Vasiliy]

Hi,

it seems that TODO list at http://kernelnewbies.org/KernelJanitors/Todo
is rather obsoleted, e.g. some tasks are already done. Is there any
renewed list?

Or I should mail to this mailing list with request to update concrete
task with proof that this task is done/etc.?

TODO List

[Benjamin BEURDOUCHE]

Hello everyone,
I am new to the mailing list and to the kernel and I was wondering if
there are some basics things I could do like fix warnings or else to avoid
to complex patches at firstŠ
There was http://kernelnewbies.org/KernelJanitors/Todo but it was last
edited 2009-04-20 14:59:47 by HenrikKretzschmar.

Any Ideas ? Thanks ! =)
Benjamin 



--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: TODO List

[Keith Woodie]

 I would be interested too.  I just joined last week.

 Thanks!
 Keith
>
> On Jul 8, 2012 9:38 AM, "Benjamin BEURDOUCHE" <dev@thecercle.org> wrote:
>>
>> Hello everyone,
>> I am new to the mailing list and to the kernel and I was wondering if
>> there are some basics things I could do like fix warnings or else to
>> avoid
>> to complex patches at firstÅ 
>> There was http://kernelnewbies.org/KernelJanitors/Todo but it was last
>> edited 2009-04-20 14:59:47 by HenrikKretzschmar.
>>
>> Any Ideas ? Thanks ! =)
>> Benjamin
>>
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe
>> kernel-janitors" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

TODO list

[Ravi Kerur]

Team,

I am planning to take up following items from TODO list. If it's already picked please let me know. 

* pci_set_dma_mask() and friends should use DMA_BIT_MASK(nn) instead of

DMA_nnBIT_MASK or 0xffff... This is not 2.4 compatible, so beware of drivers with same code. [D: http://marc.theaimsgroup.com/?t\x108001993000001] Don't forget to #include dma-mapping.h

* check kmallocs for things like GFP_DMA without a memtype. 


Thanks,

Ravi

Re: TODO list

[Dan Carpenter]

On Fri, Apr 03, 2015 at 01:40:35PM -0700, Ravi Kerur wrote:
> Team,
> 
> I am planning to take up following items from TODO list. If it's already picked please let me know. 
> 
> * pci_set_dma_mask() and friends should use DMA_BIT_MASK(nn) instead of
> 
> DMA_nnBIT_MASK or 0xffff... This is not 2.4 compatible, so beware of drivers with same code. [D: http://marc.theaimsgroup.com/?t\x108001993000001] Don't forget to #include dma-mapping.h
> 
> * check kmallocs for things like GFP_DMA without a memtype. 
> 

The TODO is desperately out of date.  No one cares about 2.4 at all.
These days we don't really allow drivers to have backwards compatability
code so they compile on old kernels.  That stuff has to be stored out of
the main kernel tree.  We also have the compat-wireless and other
similar ways of backporting drivers.

There are still the occasional GFP_DMA without a memtype issue.  I'm not
certain what the fix is for those.  You could probably find them using
Coccinelle.

regards,
dan carpenter

Re: TODO list

[Ravi Kerur]

On 4/7/2015 12:49 AM, Dan Carpenter wrote:
> On Fri, Apr 03, 2015 at 01:40:35PM -0700, Ravi Kerur wrote:
>> Team,
>>
>> I am planning to take up following items from TODO list. If it's already picked please let me know. 
>>
>> * pci_set_dma_mask() and friends should use DMA_BIT_MASK(nn) instead of
>>
>> DMA_nnBIT_MASK or 0xffff... This is not 2.4 compatible, so beware of drivers with same code. [D: http://marc.theaimsgroup.com/?t\x108001993000001] Don't forget to #include dma-mapping.h
>>
>> * check kmallocs for things like GFP_DMA without a memtype. 
>>
> 
> The TODO is desperately out of date.  No one cares about 2.4 at all.
> These days we don't really allow drivers to have backwards compatability
> code so they compile on old kernels.  That stuff has to be stored out of
> the main kernel tree.  We also have the compat-wireless and other
> similar ways of backporting drivers.

Thanks Dan. Do you recommend anything else for contribution? I am not a
newbie to kernel but never contributed to kernel before so any inputs
appreciated.

Thanks,
Ravi
> 
> There are still the occasional GFP_DMA without a memtype issue.  I'm not
> certain what the fix is for those.  You could probably find them using
> Coccinelle.
> 
> regards,
> dan carpenter
> 

Re: TODO list

[Dan Carpenter]

On Wed, Apr 08, 2015 at 05:36:01PM -0700, Ravi Kerur wrote:
> 
> 
> On 4/7/2015 12:49 AM, Dan Carpenter wrote:
> > On Fri, Apr 03, 2015 at 01:40:35PM -0700, Ravi Kerur wrote:
> >> Team,
> >>
> >> I am planning to take up following items from TODO list. If it's already picked please let me know. 
> >>
> >> * pci_set_dma_mask() and friends should use DMA_BIT_MASK(nn) instead of
> >>
> >> DMA_nnBIT_MASK or 0xffff... This is not 2.4 compatible, so beware of drivers with same code. [D: http://marc.theaimsgroup.com/?t\x108001993000001] Don't forget to #include dma-mapping.h
> >>
> >> * check kmallocs for things like GFP_DMA without a memtype. 
> >>
> > 
> > The TODO is desperately out of date.  No one cares about 2.4 at all.
> > These days we don't really allow drivers to have backwards compatability
> > code so they compile on old kernels.  That stuff has to be stored out of
> > the main kernel tree.  We also have the compat-wireless and other
> > similar ways of backporting drivers.
> 
> Thanks Dan. Do you recommend anything else for contribution? I am not a
> newbie to kernel but never contributed to kernel before so any inputs
> appreciated.

There is always stuff to fix in staging.  It's at all levels of
difficulty.

regards,
dan carpenter

Re: TODO list

[Ravi Kerur]

On 4/9/2015 1:48 AM, Dan Carpenter wrote:
> On Wed, Apr 08, 2015 at 05:36:01PM -0700, Ravi Kerur wrote:
>>
>>
>> On 4/7/2015 12:49 AM, Dan Carpenter wrote:
>>> On Fri, Apr 03, 2015 at 01:40:35PM -0700, Ravi Kerur wrote:
>>>> Team,
>>>>
>>>> I am planning to take up following items from TODO list. If it's already picked please let me know. 
>>>>
>>>> * pci_set_dma_mask() and friends should use DMA_BIT_MASK(nn) instead of
>>>>
>>>> DMA_nnBIT_MASK or 0xffff... This is not 2.4 compatible, so beware of drivers with same code. [D: http://marc.theaimsgroup.com/?t\x108001993000001] Don't forget to #include dma-mapping.h
>>>>
>>>> * check kmallocs for things like GFP_DMA without a memtype. 
>>>>
>>>
>>> The TODO is desperately out of date.  No one cares about 2.4 at all.
>>> These days we don't really allow drivers to have backwards compatability
>>> code so they compile on old kernels.  That stuff has to be stored out of
>>> the main kernel tree.  We also have the compat-wireless and other
>>> similar ways of backporting drivers.
>>
>> Thanks Dan. Do you recommend anything else for contribution? I am not a
>> newbie to kernel but never contributed to kernel before so any inputs
>> appreciated.
> 
> There is always stuff to fix in staging.  It's at all levels of
> difficulty.

Can you please point me to the link or anything which lists what needs to be done. I can pick some of it.

Thanks,
Ravi

> 
> regards,
> dan carpenter
> 

Re: TODO list

[Julia Lawall]

On Thu, 9 Apr 2015, Ravi Kerur wrote:

> 
> 
> On 4/9/2015 1:48 AM, Dan Carpenter wrote:
> > On Wed, Apr 08, 2015 at 05:36:01PM -0700, Ravi Kerur wrote:
> >>
> >>
> >> On 4/7/2015 12:49 AM, Dan Carpenter wrote:
> >>> On Fri, Apr 03, 2015 at 01:40:35PM -0700, Ravi Kerur wrote:
> >>>> Team,
> >>>>
> >>>> I am planning to take up following items from TODO list. If it's already picked please let me know. 
> >>>>
> >>>> * pci_set_dma_mask() and friends should use DMA_BIT_MASK(nn) instead of
> >>>>
> >>>> DMA_nnBIT_MASK or 0xffff... This is not 2.4 compatible, so beware of drivers with same code. [D: http://marc.theaimsgroup.com/?t\x108001993000001] Don't forget to #include dma-mapping.h
> >>>>
> >>>> * check kmallocs for things like GFP_DMA without a memtype. 
> >>>>
> >>>
> >>> The TODO is desperately out of date.  No one cares about 2.4 at all.
> >>> These days we don't really allow drivers to have backwards compatability
> >>> code so they compile on old kernels.  That stuff has to be stored out of
> >>> the main kernel tree.  We also have the compat-wireless and other
> >>> similar ways of backporting drivers.
> >>
> >> Thanks Dan. Do you recommend anything else for contribution? I am not a
> >> newbie to kernel but never contributed to kernel before so any inputs
> >> appreciated.
> > 
> > There is always stuff to fix in staging.  It's at all levels of
> > difficulty.
> 
> Can you please point me to the link or anything which lists what needs to be done. I can pick some of it.

You can run checkpatch, or other tools and fix the things that they 
highlight.  Once you start really looking at the code, you are likely to 
see other things that can be improved as well.  Some staging drivers also 
have TODO lists.

julia

Re: TODO list

[Ravi Kerur]

On 4/9/2015 10:34 PM, Julia Lawall wrote:
> 
> 
> On Thu, 9 Apr 2015, Ravi Kerur wrote:
> 
>>
>>
>> On 4/9/2015 1:48 AM, Dan Carpenter wrote:
>>> On Wed, Apr 08, 2015 at 05:36:01PM -0700, Ravi Kerur wrote:
>>>>
>>>>
>>>> On 4/7/2015 12:49 AM, Dan Carpenter wrote:
>>>>> On Fri, Apr 03, 2015 at 01:40:35PM -0700, Ravi Kerur wrote:
>>>>>> Team,
>>>>>>
>>>>>> I am planning to take up following items from TODO list. If it's already picked please let me know. 
>>>>>>
>>>>>> * pci_set_dma_mask() and friends should use DMA_BIT_MASK(nn) instead of
>>>>>>
>>>>>> DMA_nnBIT_MASK or 0xffff... This is not 2.4 compatible, so beware of drivers with same code. [D: http://marc.theaimsgroup.com/?t\x108001993000001] Don't forget to #include dma-mapping.h
>>>>>>
>>>>>> * check kmallocs for things like GFP_DMA without a memtype. 
>>>>>>
>>>>>
>>>>> The TODO is desperately out of date.  No one cares about 2.4 at all.
>>>>> These days we don't really allow drivers to have backwards compatability
>>>>> code so they compile on old kernels.  That stuff has to be stored out of
>>>>> the main kernel tree.  We also have the compat-wireless and other
>>>>> similar ways of backporting drivers.
>>>>
>>>> Thanks Dan. Do you recommend anything else for contribution? I am not a
>>>> newbie to kernel but never contributed to kernel before so any inputs
>>>> appreciated.
>>>
>>> There is always stuff to fix in staging.  It's at all levels of
>>> difficulty.
>>
>> Can you please point me to the link or anything which lists what needs to be done. I can pick some of it.
> 
> You can run checkpatch, or other tools and fix the things that they 
> highlight.  Once you start really looking at the code, you are likely to 
> see other things that can be improved as well.  Some staging drivers also 
> have TODO lists.
> 

My question was which subsystem or specific area to start? Should I pick some random subsystem of my interest and start working on it? 

-Ravi
 
> julia
> 

Re: TODO list

[Julia Lawall]

On Fri, 10 Apr 2015, Ravi Kerur wrote:

> 
> 
> On 4/9/2015 10:34 PM, Julia Lawall wrote:
> > 
> > 
> > On Thu, 9 Apr 2015, Ravi Kerur wrote:
> > 
> >>
> >>
> >> On 4/9/2015 1:48 AM, Dan Carpenter wrote:
> >>> On Wed, Apr 08, 2015 at 05:36:01PM -0700, Ravi Kerur wrote:
> >>>>
> >>>>
> >>>> On 4/7/2015 12:49 AM, Dan Carpenter wrote:
> >>>>> On Fri, Apr 03, 2015 at 01:40:35PM -0700, Ravi Kerur wrote:
> >>>>>> Team,
> >>>>>>
> >>>>>> I am planning to take up following items from TODO list. If it's already picked please let me know. 
> >>>>>>
> >>>>>> * pci_set_dma_mask() and friends should use DMA_BIT_MASK(nn) instead of
> >>>>>>
> >>>>>> DMA_nnBIT_MASK or 0xffff... This is not 2.4 compatible, so beware of drivers with same code. [D: http://marc.theaimsgroup.com/?t\x108001993000001] Don't forget to #include dma-mapping.h
> >>>>>>
> >>>>>> * check kmallocs for things like GFP_DMA without a memtype. 
> >>>>>>
> >>>>>
> >>>>> The TODO is desperately out of date.  No one cares about 2.4 at all.
> >>>>> These days we don't really allow drivers to have backwards compatability
> >>>>> code so they compile on old kernels.  That stuff has to be stored out of
> >>>>> the main kernel tree.  We also have the compat-wireless and other
> >>>>> similar ways of backporting drivers.
> >>>>
> >>>> Thanks Dan. Do you recommend anything else for contribution? I am not a
> >>>> newbie to kernel but never contributed to kernel before so any inputs
> >>>> appreciated.
> >>>
> >>> There is always stuff to fix in staging.  It's at all levels of
> >>> difficulty.
> >>
> >> Can you please point me to the link or anything which lists what needs to be done. I can pick some of it.
> > 
> > You can run checkpatch, or other tools and fix the things that they 
> > highlight.  Once you start really looking at the code, you are likely to 
> > see other things that can be improved as well.  Some staging drivers also 
> > have TODO lists.
> > 
> 
> My question was which subsystem or specific area to start? Should I pick some random subsystem of my interest and start working on it? 

Dan suggested staging.  In terms of learning, it doesn't matter what you 
choose to get started.  You should avoid the following drivers, though, as 
they are on the way out of the kernel:

i2o
line6
media/parport
media/tlg2300
media/vino

julia

Re: TODO list

[Dan Carpenter]

On Mon, Apr 13, 2015 at 02:46:53PM -0700, Ravi Kerur wrote:
> Team,
> 
> I will take up net/sched files and get a clean checkpatch run on them. I am working on a project which involves this piece of code and as part of learning the code I can clean-up the files. I ran checkpatch on some of them and I do see that it needs cleaning. For e.g.
> 
> #:~/git/kernels/staging$ perl scripts/checkpatch.pl -f net/sched/act_api.c
> WARNING: networking block comments don't use an empty /* line, use /* Comment...
> #41: FILE: net/sched/act_api.c:41:
> +	/*
> +	 * gen_estimator est_timer() might access p->tcfc_locki
> 
> CHECK: Comparison to NULL could be written "!nest"
> #95: FILE: net/sched/act_api.c:95:
> +			if (nest = NULL)
> ...
> [...]

No one cares about either of those things.  If it's a drivers/staging
patch then we would merge it, but if it's a patch to net/sched/act_api.c
they will probably just get annoyed with you.

regards,
dan carpenter

Re: TODO list

[Ravi Kerur]

On 4/13/2015 3:02 PM, Dan Carpenter wrote:
> On Mon, Apr 13, 2015 at 02:46:53PM -0700, Ravi Kerur wrote:
>> Team,
>>
>> I will take up net/sched files and get a clean checkpatch run on them. I am working on a project which involves this piece of code and as part of learning the code I can clean-up the files. I ran checkpatch on some of them and I do see that it needs cleaning. For e.g.
>>
>> #:~/git/kernels/staging$ perl scripts/checkpatch.pl -f net/sched/act_api.c
>> WARNING: networking block comments don't use an empty /* line, use /* Comment...
>> #41: FILE: net/sched/act_api.c:41:
>> +	/*
>> +	 * gen_estimator est_timer() might access p->tcfc_locki
>>
>> CHECK: Comparison to NULL could be written "!nest"
>> #95: FILE: net/sched/act_api.c:95:
>> +			if (nest = NULL)
>> ...
>> [...]
> 
> No one cares about either of those things.  If it's a drivers/staging
> patch then we would merge it, but if it's a patch to net/sched/act_api.c
> they will probably just get annoyed with you.
> 

Thanks, The reason I didn't pick from drivers/staging is that I don't have necessary hardware to test the changes. Hence I chose something which can be tested without any restriction and get it done. Do you have any recommendations?

Thanks,
Ravi

> regards,
> dan carpenter
> 

Re: TODO list

[Dan Carpenter]

On Mon, Apr 13, 2015 at 03:42:38PM -0700, Ravi Kerur wrote:
> Thanks, The reason I didn't pick from drivers/staging is that I don't
> have necessary hardware to test the changes. Hence I chose something
> which can be tested without any restriction and get it done. Do you
> have any recommendations?

Most people send their staging patches without testing, honestly.

Otherwise just restrict yourself to drivers/.

Also checkpatch on its own is not really a justification for sending
patches outside of staging/.  The patch has to make the code better for
humans.

regards,
dan carpenter

todo list

[Krzysztof]

hi,
I'm quite newbie in netfilter, I wonder what can I do to improve my
skills. I was looking for a TODO list but I couldn't find it. Please
give me some information. Thanks for advices in advance.

Regards,
Krzychu

TODO List

[SMohideen]

Hi,
Where we can obtain the TODO list of NetFilter projects. I have seen in
the archives, but none found in the latest release.

Thanks
Mohi

Re: TODO List

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 633 bytes --]

On Tue, Oct 25, 2005 at 02:20:26PM +0530, SMohideen wrote:
> Hi,
> Where we can obtain the TODO list of NetFilter projects. I have seen in
> the archives, but none found in the latest release.

We don't have an official todo list at the moment, sorry :(

-- 
- Harald Welte <laforge@netfilter.org>                 http://netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

RE: TODO List

[Jamey Hicks]

> 2	FTL fix

What's wrong with FTL?
What's the state of it wrt licensing M-Systems patents?  Can it be used for
systems with onboard flash?

-Jamey


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: TODO List

[Trevor Woolven]

Jamey Hicks wrote:
> 
> > 2     FTL fix
> 
> What's wrong with FTL?
> What's the state of it wrt licensing M-Systems patents?  Can it be used for
> systems with onboard flash?
> 
> -Jamey
DW thinks FTL needs to be Big-Endian on BE machines and Little-Endian on
LE machines and never the twain shall meet, which seems strange. He
posted this observation to the list a while back and would like further
information on it before proceeding with a fix.

I'm not sure about the licensing issue, is this another subject for the
TODO list?

Best regards

Trevor.
-- 
Zentropix Inc - a Lineo company

Tel: +44 (0)1273 234 647	 Fax: +44 (0)1273 704 482

Visit http://www.zentropix.com/ for Real Time Linux Tools
Visit http://www.realtimelinux.org/ for Real Time Linux Information


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: TODO List

[David Woodhouse]

jamey@crl.dec.com said:
>  What's wrong with FTL?

Technically, there are two main problems.

Firstly, it's broken - it works for a while and then seems to corrupt the
 FTL. I can't see how I did that in porting David Hinds' code to use the MTD
flash access routines - so it could be an SMP issue (I'm testing on SMP) or it
could be because I'm testing on the RAM device, which calls the 'erase done'
callback directly from within the erase routine..

Secondly, it makes no attempt to handle byte-swapping - so if you run it on a 
BE machine, then your FTL is all BE, which doesn't conform to the spec, and 
obviously won't be portable to LE machines. We need to pepper it with 
cpu_to_le16() and le16_to_cpu() all over the place.

> What's the state of it wrt licensing M-Systems patents? 

M-Systems have a patent which covers FTL, but they've given a licence to use 
it on all PCMCIA devices. They have not granted a licence to use it with 
non-PCMCIA devices.

>  Can it be used for systems with onboard flash? 

I assume that's not actually the question you meant to ask.

Can it be used? Yes - although you'd do better to use JFFS.
May it be used? Only if you live in the Free World.



--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

TODO List

[Trevor Woolven]

Hi Everyone,

Dave Woodhouse and I had a meeting yesterday and we came up with the
following list of things that need doing to/fixing in the MTD code:

1	Write Support
	a	ECC
	b	Bad block handling (static)
	c	Bad block detection and handling (dynamic)
	d	Timing constraints
	e	Asynchronous writes

2	FTL fix

3	Support for NOR flash/PCMCIA

4	Support utilities
	a	Formatting
	b	Bad sector/block detection
	c	Consistency checking

5	Documentation
	a	Architectural description
	b	User Guide and API listing
	c	...

6	DOC Millenium support

7	Fix the character device memory copy to/from user space

8	JFFS/FFS2 support

9	GRUB
	a	Filesystem support (NFTL, JFFS etc)
	b	MTD support

10	Execute-in-place

We attempted to prioritize them as we saw fit with the following two
goals: 
	a)	submission to the main-stream linux kernel (2.4/2.5)
	b)	production of a fully GPL alternative to what M-Systems offer

Since Dave's still officially on holiday I agreed to post this to the
list. We're after your opinions and suggestions regarding the TODO list
and the two immediate goals for this work. We're also after volunteers
to take on various parts of the development. Please feel free to comment
upon the above.

Thanks,

Trevor.

--
Zentropix Inc - a Lineo company

Tel: +44 (0)1273 234 647	 Fax: +44 (0)1273 704 482

Visit http://www.zentropix.com/ for Real Time Linux Tools
Visit http://www.realtimelinux.org/ for Real Time Linux Information


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org