linux-kernel - comedi: some questions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <87zldpeq6x.fsf@free.fr>
Date:	Thu, 07 May 2009 02:01:42 +0200
From:	Alexis Berlemont <alexis.berlemont@...il.com>
To:	linux-kernel@...r.kernel.org
Cc:	Greg KH <greg@...ah.com>, Ian Abbott <abbotti@....co.uk>
Subject: comedi: some questions 

Hi,

Please find attached a patch related with the Comedi layer. This patch
is just a proposal (among two) to change the way the ranges tables are
managed. 

I first tried to send it to the Comedi community three weeks ago:
http://groups.google.com/group/comedi_list/browse_thread/thread/85be8195ddf52896

One week after my first mail, Ian Abott told me the Comedi CVS tree
would not integrate any code change other than bug fix; he redirected
me to the linux-next mailing list. According to him, the clean up
effort should be hosted on the staging area of the linux-next tree. 

Then, I sent the patches (adapted for the linux-next git tree) to the
linux-next mailing list:
http://marc.info/?l=linux-next&m=124078248400745&w=2

Greg KH asked me to send them to the Comedi community before asking
for integration into the staging area (which I already did). After a
few mails, it became clear that the suitable procedure was to send
patches to the Comedi mailing-list and CC Greg KH. Thus, with the
Comedi maintainers' agreements, GKH will integrate them. 

I am kind of puzzled. That is why I thought mailing the LKML might be
interesting. 

It seems like the original Comedi developers (the ones who maintain
the original CVS tree) do not seem involved in the developments for
the integration of Comedi into mainstream. However, any contribution
must go through them. That might slow down the evolutions. No ? 

By the way, I have been waiting for one more week and I still have no
feedback on my little proposals which are, I think, meaningless
compared to other issues (kcomedilib, buffer management, user
interfaces, etc.). I should ask once more.

That leads to the last point which I do not understand: Comedi is
supposed to undergo a host of changes before considering integration
into mainline (here is a mail which lists some of them:
http://lkml.org/lkml/2009/2/9/335). That should imply many
incompatibilities with the original Comedi tree; so why keeping
coherency with upstream?

Alexis.

View attachment "0001-Introduce-a-container-structure-for-ranges-so-as-to.patch" of type "text/x-diff" (7328 bytes)