Re: [PATCH] mxser: make an experimental clone

Re: [PATCH] mxser: make an experimental clone

[Andrew Morton]

On Wed, 20 Sep 2006 16:06:55 +0200 (CEST)
Jiri Slaby <jirislaby@gmail.com> wrote:

> Andrew Morton wrote:
> > Ho hum, this is hard.  I guess breaking the driver is one way to find out
> > who is using it, but those who redistribute the kernel for a living might
> > not appreciate the technique.
> > 
> > Perhaps we could create an mxser-new.c and offer that in config, plan to
> > remove mxser.c N months hence?
> 
> Ok, here's a patch doing this. When you apply it, drop
> mxser-upgrade-to-191.patch, please, to get back unmodified version.
> 

It was, umm, naive to assume that was the only outstanding patch against
mxser.c.  I had four patches.  One wasn't actually in use and one I just
dropped, so we now have
serial-fix-up-offenders-peering-at-baud-bits-directly.patch and
const-struct-tty_operations.patch.

> 
> mxser: clone a new driver
> 
> Clone a new driver for moxa smartio devices. It contains update to version
> 1.9.1 from Moxa site and static to dynamic structures (including some
> renaming) conversion for further work -- converting to pci probing.

That wasn't a good way to do this.  It would have been (much) better to
have one patch which copies mxser.c to mxser_new.c and *nothing else*. 
Then, new patches which update mxser_new.c.

So I have converted your patch into one which simply copies mxser.[ch] to
mxser_new.[ch] and which makes no other changes.  The versions which were
copied were those _after_ the two pending patches were applied.  Please
send updates against those new files, thanks.

Re: [PATCH] mxser: make an experimental clone

[Jiri Slaby]

Andrew Morton wrote:
> On Wed, 20 Sep 2006 16:06:55 +0200 (CEST)
> Jiri Slaby <jirislaby@gmail.com> wrote:
> 
>> Andrew Morton wrote:
>>> Ho hum, this is hard.  I guess breaking the driver is one way to find out
>>> who is using it, but those who redistribute the kernel for a living might
>>> not appreciate the technique.
>>>
>>> Perhaps we could create an mxser-new.c and offer that in config, plan to
>>> remove mxser.c N months hence?
>> Ok, here's a patch doing this. When you apply it, drop
>> mxser-upgrade-to-191.patch, please, to get back unmodified version.
>>
> 
> It was, umm, naive to assume that was the only outstanding patch against
> mxser.c.  I had four patches.  One wasn't actually in use and one I just
> dropped, so we now have
> serial-fix-up-offenders-peering-at-baud-bits-directly.patch and
> const-struct-tty_operations.patch.

Aargh. Sorry for that, next time I'll make a revert- variant.

>> mxser: clone a new driver
>>
>> Clone a new driver for moxa smartio devices. It contains update to version
>> 1.9.1 from Moxa site and static to dynamic structures (including some
>> renaming) conversion for further work -- converting to pci probing.
> 
> That wasn't a good way to do this.  It would have been (much) better to
> have one patch which copies mxser.c to mxser_new.c and *nothing else*. 
> Then, new patches which update mxser_new.c.
> 
> So I have converted your patch into one which simply copies mxser.[ch] to
> mxser_new.[ch] and which makes no other changes.  The versions which were
> copied were those _after_ the two pending patches were applied.  Please
> send updates against those new files, thanks.

Ok, thank you,
-- 
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