-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I compile linux-2.6.12_r2 sources with jsm support, but Digi Neo 8 is
unsupported.
after some code-modifications it works fine.
lspci -v
0000:00:09.0 Serial controller: Digi International Digi Neo 8 (rev 02)
(prog-if 02 [16550])
~ Subsystem: Digi International Digi Neo 8
~ Flags: fast devsel, IRQ 16
~ Memory at feb7e000 (32-bit, non-prefetchable)
diff -r linux-2.6.12-rc2/drivers/serial/jsm/jsm_driver.c
linux-2.6.12-rc2-modified/drivers/serial/jsm/jsm_driver.c
62a63
|
67a69
| { PCI_DEVICE (PCI_VENDOR_ID_DIGI,
PCI_DEVICE_NEO_8_DID), 0, 0, 4 },
76a79
| { PCI_DEVICE_NEO_8_DID , 8 },
169a173
| case PCI_DEVICE_NEO_8_DID:
diff -r linux-2.6.12-rc2/include/linux/pci_ids.h
linux-2.6.12-rc2-modified/include/linux/pci_ids.h
1532a1533
| #define PCI_DEVICE_NEO_8_DID 0x00B1
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCW7oFHI+uMg2HaCcRAraBAJ9ttNr3kTCIM4ztWk6DuMwwmaMVOgCeO8Rl
N7idPCAnZOIevdD4Wguty9w=
=ZFjm
-----END PGP SIGNATURE-----
Hi,
Not having the 8 port board listed in the JSM driver was actually
intentional.
IBM and Digi only want the 2 port Neo board supported in the JSM driver,
as IBM are only using the 2 port Neo products.
Digi has a different and more fully featured driver for the other port
count boards. (1, 4, 8).
If you would like, I can send you the source tarball of this version of
the driver instead,
its called DGNC, and contains more diagnostics and utilities.
LKML, please, do *NOT* apply this patch to the kernel!
It will cause conflicts if our customers have both the Digi DGNC and
IBM/Digi JSM drivers installed!
Thanks!
Scott Kilau
-----Original Message-----
From: Ihalainen Nickolay [mailto:[email protected]]
Sent: Tuesday, April 12, 2005 7:14 AM
To: Kilau, Scott
Cc: [email protected]; [email protected]
Subject: Digi Neo 8: linux-2.6.12_r2 jsm driver
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I compile linux-2.6.12_r2 sources with jsm support, but Digi Neo 8 is
unsupported.
after some code-modifications it works fine.
lspci -v
0000:00:09.0 Serial controller: Digi International Digi Neo 8 (rev 02)
(prog-if 02 [16550])
~ Subsystem: Digi International Digi Neo 8
~ Flags: fast devsel, IRQ 16
~ Memory at feb7e000 (32-bit, non-prefetchable)
diff -r linux-2.6.12-rc2/drivers/serial/jsm/jsm_driver.c
linux-2.6.12-rc2-modified/drivers/serial/jsm/jsm_driver.c
62a63
|
67a69
| { PCI_DEVICE (PCI_VENDOR_ID_DIGI,
PCI_DEVICE_NEO_8_DID), 0, 0, 4 },
76a79
| { PCI_DEVICE_NEO_8_DID , 8 },
169a173
| case PCI_DEVICE_NEO_8_DID:
diff -r linux-2.6.12-rc2/include/linux/pci_ids.h
linux-2.6.12-rc2-modified/include/linux/pci_ids.h
1532a1533
| #define PCI_DEVICE_NEO_8_DID 0x00B1
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCW7oFHI+uMg2HaCcRAraBAJ9ttNr3kTCIM4ztWk6DuMwwmaMVOgCeO8Rl
N7idPCAnZOIevdD4Wguty9w=
=ZFjm
-----END PGP SIGNATURE-----
On Tue, Apr 12, 2005 at 04:13:43PM +0400, Ihalainen Nickolay wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I compile linux-2.6.12_r2 sources with jsm support, but Digi Neo 8 is
> unsupported.
> after some code-modifications it works fine.
The patch is badly mangled, please resend with a good mailer (e.g.
mutt) or as an attachment.
Also the driver has changed a little in -mm, can you provide a diff
against that?
On Tue, Apr 12, 2005 at 09:02:42AM -0500, Kilau, Scott wrote:
> LKML, please, do *NOT* apply this patch to the kernel!
> It will cause conflicts if our customers have both the Digi DGNC and
> IBM/Digi JSM drivers installed!
Who cares? If you're driver was written properly (which I hope for you)
it'll just skip a device that's bound to the jsm driver already.
And having additional hardware support is always a good thing, especially
if it's as trivial as that patch.
We (Digi) cares.
We want people to use our DGNC driver over the JSM driver in all
cases except the 2 port model of the board.
This is because the DGNC driver contains extra features that the JSM
driver
Has stripped out, to get into the kernel sources,
and our other customers WANT these features!
We cannot have a situation where the JSM driver takes control of the PCI
card
before the DGNC driver can take it first!
Please, do *NOT* add this patch!!!
Do I, as a copyright holder on the code in question, have any rights at
all,
or are you just going to trample over my wishes, in your zeal?
Scott
-----Original Message-----
From: Christoph Hellwig [mailto:[email protected]]
Sent: Tuesday, April 12, 2005 9:44 AM
To: Kilau, Scott
Cc: Ihalainen Nickolay; [email protected]; [email protected]
Subject: Re: Digi Neo 8: linux-2.6.12_r2 jsm driver
On Tue, Apr 12, 2005 at 09:02:42AM -0500, Kilau, Scott wrote:
> LKML, please, do *NOT* apply this patch to the kernel!
> It will cause conflicts if our customers have both the Digi DGNC and
> IBM/Digi JSM drivers installed!
Who cares? If you're driver was written properly (which I hope for you)
it'll just skip a device that's bound to the jsm driver already.
And having additional hardware support is always a good thing,
especially
if it's as trivial as that patch.
On Tue, Apr 12, 2005 at 09:55:10AM -0500, Kilau, Scott wrote:
> We (Digi) cares.
>
> We want people to use our DGNC driver over the JSM driver in all
> cases except the 2 port model of the board.
And we (kernel developers) don't care what drivers digi wants people
to use. We empower people to use free software with whatever hardware
can be supported. Our drivers are often not from vendors at all, and
even when vendor drivers exist we often support better (in our opinion)
drivers
>
> This is because the DGNC driver contains extra features that the JSM
> driver
> Has stripped out, to get into the kernel sources,
> and our other customers WANT these features!
There are people who just want the card supported. There's no reason
to deny the driver to them.
> We cannot have a situation where the JSM driver takes control of the PCI
> card
> before the DGNC driver can take it first!
Sure, we can have the situation easily. If you want us to care for your
other driver make sure it's submitted for kernel inclusion.
> Please, do *NOT* add this patch!!!
>
> Do I, as a copyright holder on the code in question, have any rights at
> all,
> or are you just going to trample over my wishes, in your zeal?
You do have lots of rights. But as you put the code under the GPL we
do have rights aswell now, and one of the most important rights you gave
us is to modify and redistribute the code under the terms of the GPL.
Christoph Hellwig wrote:
> On Tue, Apr 12, 2005 at 04:13:43PM +0400, Ihalainen Nickolay wrote:
> Also the driver has changed a little in -mm, can you provide a diff
> against that?
Sorry.
>
diff -up -r linux-2.6.12-rc2/drivers/serial/jsm/jsm_driver.c
linux-2.6.12-rc2-modified/drivers/serial/jsm/jsm_driver.c
--- linux-2.6.12-rc2/drivers/serial/jsm/jsm_driver.c 2005-04-11
13:08:16.000000000 +0000
+++ linux-2.6.12-rc2-modified/drivers/serial/jsm/jsm_driver.c
2005-04-11 12:58:51.000000000 +0000
@@ -60,11 +60,13 @@ int jsm_driver_state = DRIVER_INITIALIZ
spinlock_t jsm_board_head_lock = SPIN_LOCK_UNLOCKED;
LIST_HEAD(jsm_board_head);
+
static struct pci_device_id jsm_pci_tbl[] = {
{ PCI_DEVICE (PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_2DB9),
0, 0, 0 },
{ PCI_DEVICE (PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_2DB9PRI),
0, 0, 1 },
{ PCI_DEVICE (PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_2RJ45),
0, 0, 2 },
{ PCI_DEVICE (PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_2RJ45PRI),
0, 0, 3 },
+ { PCI_DEVICE (PCI_VENDOR_ID_DIGI, PCI_DEVICE_NEO_8_DID),
0, 0, 4 },
{ 0,} /* 0 terminated
list. */
};
MODULE_DEVICE_TABLE(pci, jsm_pci_tbl);
@@ -74,6 +76,7 @@ static struct board_id jsm_Ids[] = {
{ PCI_DEVICE_NEO_2DB9PRI_PCI_NAME, 2 },
{ PCI_DEVICE_NEO_2RJ45_PCI_NAME, 2 },
{ PCI_DEVICE_NEO_2RJ45PRI_PCI_NAME, 2 },
+ { PCI_DEVICE_NEO_8_DID , 8 },
{ NULL, 0 }
};
@@ -167,6 +170,7 @@ static int jsm_found_board(struct pci_de
case PCI_DEVICE_ID_NEO_2DB9PRI:
case PCI_DEVICE_ID_NEO_2RJ45:
case PCI_DEVICE_ID_NEO_2RJ45PRI:
+ case PCI_DEVICE_NEO_8_DID:
/*
* This chip is set up 100% when we get to it.
diff -up -r linux-2.6.12-rc2/include/linux/pci_ids.h
linux-2.6.12-rc2-modified/include/linux/pci_ids.h
--- linux-2.6.12-rc2/include/linux/pci_ids.h 2005-04-11
13:08:16.000000000 +0000
+++ linux-2.6.12-rc2-modified/include/linux/pci_ids.h 2005-04-11
12:58:04.000000000 +0000
@@ -1530,6 +1530,7 @@
#define PCI_DEVICE_ID_NEO_2DB9PRI 0x00C9
#define PCI_DEVICE_ID_NEO_2RJ45 0x00CA
#define PCI_DEVICE_ID_NEO_2RJ45PRI 0x00CB
+#define PCI_DEVICE_NEO_8_DID 0x00B1
#define PCI_VENDOR_ID_MUTECH 0x1159
#define PCI_DEVICE_ID_MUTECH_MV1000 0x0001
Wendy and I released under the GPL, and as such, I know legally you have
the right
to modify the code the way you see fit.
However, when the copyright holder says "No, please don't add that
code",
and gives *GOOD* reasons why, you should respect that decision.
So if I don't sign off on this change, does the matter?
If not, what good is having the sign off section for patches that must
go through the maintainer?
I would have no problem submitting the other driver (DGNC) for kernel
inclusion,
and have tried repeatedly in the past.
However, I am NOT willing to strip out many of the features our
customers,
(and as such, your USERS) want, which is what happened with the JSM
driver.
> There are people who just want the card supported. There's no reason
> to deny the driver to them.
Oh, it *is* supported, using our GPL'ed DGNC driver available on our
ftp/web site.
This is not some argument of closed binaries versus open source
binaries,
As both the JSM and DGNC drivers are completely open source and GPL'ed.
This is about having the users of this card end up
getting a worse experience by using the JSM driver.
However, in case it actually matters, (which I know it won't),
"I, Scott Kilau, *DO NOT* sign off on this patch to the JSM driver".
Scott Kilau
Digi International
On Tue, Apr 12, 2005 at 10:30:19AM -0500, Kilau, Scott wrote:
> However, when the copyright holder says "No, please don't add that
> code",
> and gives *GOOD* reasons why, you should respect that decision.
You didn't not give a single good reason. Only political bullshit.
> So if I don't sign off on this change, does the matter?
No.
> You didn't not give a single good reason. Only political bullshit.
How does "having more features" as a reason equal "political bullshit" ?
I am done with this thread, because I know continuing the flaming is
what you live for.
Do what you want, because I know you will.
However, again, I want to state to everyone else on the list:
"I, Scott Kilau, as the copyright holder of the JSM driver, do NOT sign
off on this change".
Scott Kilau
On Tue, Apr 12, 2005 at 10:30:19AM -0500, Kilau, Scott wrote:
> However, I am NOT willing to strip out many of the features our
> customers, (and as such, your USERS) want, which is what happened with
> the JSM driver.
What features? Didn't we end up with a valid resolution to all of the
additional stuff in the jsm driver that you originally asked for? Why
not work on adding those new features to the serial core, and then there
would be no issue with accepting your other driver?
thanks,
greg k-h
On Tue, 2005-04-12 10:30:19 -0500, Kilau, Scott <[email protected]>
wrote in message <[email protected]>:
> > There are people who just want the card supported. There's no reason
> > to deny the driver to them.
>
> Oh, it *is* supported, using our GPL'ed DGNC driver available on our
> ftp/web site.
>
> This is not some argument of closed binaries versus open source
> binaries,
> As both the JSM and DGNC drivers are completely open source and GPL'ed.
So then please do *all* the work, not only the first half. Writing a
driver is a nice thing, but doesn't actually help anybody. Doing a
driver for eg. Linux means to *care* for it. That is, writing it is only
the very first step of a longer way. The next step is to supply patches
for review. Then you'll get some feedback and you're expected to work
the issues out. Then you can again submit patches -- and repeat this
until it's merged.
> This is about having the users of this card end up
> getting a worse experience by using the JSM driver.
Then please work on getting your driver included into Linus' and Andrews
kernel sources. For some time, both drivers may co-exist, but once one
driver is *really* superior over the other one and there are *no* issues
left that force people to use the worse driver, that one will die out at
some time.
But please be prepared to be in a competitive position. You've won't get
your driver included by just telling once about it; you'll need to work
towards that goal, and probably monitor the driver to be useable in the
future.
MfG, JBG
--
Jan-Benedict Glaw [email protected] . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
Hi Greg,
> What features? Didn't we end up with a valid resolution to all of the
> additional stuff in the jsm driver that you originally asked for? Why
> not work on adding those new features to the serial core, and then
there
> would be no issue with accepting your other driver?
I appreciate your "calm" response. =)
DPA (Digi Port Authority) support (the special ioctls)
and /proc (and /sys) files were left unresolved.
Wendy had no choice but to remove them to get the driver
into the kernel sources.
IBM was okay with removing them, so I was okay with doing it as well,
as the whole point of the JSM driver is to support IBM's card directly.
However, removing those things are just unacceptable for Digi for our
cards.
I understand your position, and I respect it.
This is why for now, I cannot submit the original DGNC driver.
However, I have taken your suggestion of moving to the serial-core to
heart,
and in the future, when I am able to drop 2.4 kernel support in the
DGNC driver, I will completely go to serial-core, like the JSM driver
has already done.
Thanks!
Scott Kilau
Hi Jan,
> But please be prepared to be in a competitive position. You've won't
get
> your driver included by just telling once about it; you'll need to
work
> towards that goal, and probably monitor the driver to be useable in
the
> future.
The JSM driver is a "stripped" down version of the DGNC driver.
There is no "competition" between these 2 drivers.
They were always intended to work side by side with each other.
Both drivers will get all fixes/changes added to them at the same time,
since 90% of the driver code is the same.
The JSM driver was forced to be stripped down when being submitted
to the kernel sources, and many extended features removed as so to be
included into the kernel, as the extended features added special ioctls
and special /proc (/sys for 2.6) files.
Oddly enough, I have had a few of our customers come back to me, after
seeing some of the previous JSM threads about yanking the extended
features,
and I quote:
> I didn't think that you would remove them. I read the posts and
> wondered *why* they wanted the management pieces removed.
> One reason to use the Digi products is for the sole fact that
> they *can* be diagnosed.
> I'm glad that Digi is still focused properly.
> I agree that committing the drivers to the main kernel
> is not the way to go if you are forced to remove dpa and ditty.
But this is neither here nor there, as Christoph has made it clear,
actual "Digi customers" don't matter.
I will let the chips fall where they will, and clean up the mess that
will soon be introduced into my driver world. =)
Scott
On Tue, Apr 12, 2005 at 11:54:04AM -0500, Kilau, Scott wrote:
> Hi Greg,
>
> > What features? Didn't we end up with a valid resolution to all of the
> > additional stuff in the jsm driver that you originally asked for? Why
> > not work on adding those new features to the serial core, and then
> there
> > would be no issue with accepting your other driver?
>
> I appreciate your "calm" response. =)
>
> DPA (Digi Port Authority) support (the special ioctls)
> and /proc (and /sys) files were left unresolved.
> Wendy had no choice but to remove them to get the driver
> into the kernel sources.
I understand.
> IBM was okay with removing them, so I was okay with doing it as well,
> as the whole point of the JSM driver is to support IBM's card directly.
>
> However, removing those things are just unacceptable for Digi for our
> cards.
Ok, but wasn't it possible to get those additional things added to the
main kernel serial core, which would then provide everything that Digi's
customers are accustomed to? And then this thread would not be an issue
at all.
And yes, I understand you need to support 2.4, but that's not a
kernel.org issue, and you can continue to have your 2.4 driver.
thanks,
greg k-h
Hi Greg, all,
> Ok, but wasn't it possible to get those additional things added to the
> main kernel serial core, which would then provide everything that
Digi's
> customers are accustomed to?
Yes, it is my intention in the future to add support for the needed
information,
probably at the /sys level.
The key is to be able to get at the tty information without
having to open up the tty/port.
Again, I understand why you required the changes in JSM,
IBM didn't need DPA support, so I had no problem with removing the
support.
However, neither IBM nor Digi wants this thread's patch to be applied,
and yet Christoph wants to do it, completely out of spite, to break our
out-of-tree open source driver.
This is the problem that I have.
Scott
> There's a consensus that if there's *any* choice, new /proc files as
> well as new ioctls shall not be introduced. So if there's management needed
Oh, keep in mind, the ioctls are not new.
They exist today, and are clearly defined in Documentation/ioctl-number.txt
> 'd' F0-FF linux/digi1.h
But we have already been down this road in a previous thread,
and I gave up on that argument as well. =)
Scott Kilau
-----Original Message-----
From: Jan-Benedict Glaw [mailto:[email protected]]
Sent: Tuesday, April 12, 2005 1:49 PM
To: Kilau, Scott
Cc: Christoph Hellwig; Ihalainen Nickolay; [email protected]; [email protected]; Wen Xiong
Subject: Re: Digi Neo 8: linux-2.6.12_r2 jsm driver
On Tue, 2005-04-12 11:42:31 -0500, Kilau, Scott <[email protected]>
wrote in message <[email protected]>:
> The JSM driver was forced to be stripped down when being submitted
> to the kernel sources, and many extended features removed as so to be
> included into the kernel, as the extended features added special ioctls
> and special /proc (/sys for 2.6) files.
There's a consensus that if there's *any* choice, new /proc files as
well as new ioctls shall not be introduced. So if there's management
needed (disclaimer: I don't own such a card), then this interface needs
to be introduced as a generic interface, which might be used by any
further drivers. We've just had this situation for some RAID cards,
where the vendor wanted to introduce a (specific for his devices)
interface. Either do it correct (as of best current practice), or don't
do it at all.
> > I didn't think that you would remove them. I read the posts and
> > wondered *why* they wanted the management pieces removed.
> > One reason to use the Digi products is for the sole fact that
> > they *can* be diagnosed.
> > I'm glad that Digi is still focused properly.
> > I agree that committing the drivers to the main kernel
> > is not the way to go if you are forced to remove dpa and ditty.
Well, again, if this features can only used by your hardware (and
there's proof that no other vendor will add these features *ever*), then
an own interface is okay. But if there's a possibility that a different
vendor *might* introduce these as well, then a generic interface needs
to be build (with first of all only one user: your driver).
> I will let the chips fall where they will, and clean up the mess that
> will soon be introduced into my driver world. =)
That's a plan. Good to head :-)
MfG, JBG
--
Jan-Benedict Glaw [email protected] . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
fuer einen Freien Staat voll Freier B?rger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
On Tue, Apr 12, 2005 at 03:21:15PM -0500, Kilau, Scott wrote:
> Hi Greg, all,
>
> > Ok, but wasn't it possible to get those additional things added to the
> > main kernel serial core, which would then provide everything that
> Digi's
> > customers are accustomed to?
>
> Yes, it is my intention in the future to add support for the needed
> information,
> probably at the /sys level.
> The key is to be able to get at the tty information without
> having to open up the tty/port.
>
> Again, I understand why you required the changes in JSM,
> IBM didn't need DPA support, so I had no problem with removing the
> support.
>
> However, neither IBM nor Digi wants this thread's patch to be applied,
> and yet Christoph wants to do it, completely out of spite, to break our
> out-of-tree open source driver.
The problem is that your "out-of-tree open source driver" is an
inadequate solution. Out of tree drivers are a pain for users,
developers, and distributors. As such, we make very little allowance
for their concerns, especially when they stand in the way of improving
things that _are_ in the kernel.
The proposed patch makes the in-tree driver work for hardware that it
didn't before which is a net good for our users. The ball is now in
your court: replace it with an acceptable version of your driver in a
timely fashion. Saying you'll get around to it some day when you're
done supporting 2.4 is not timely. Nor does it serve your users.
Alternately, provide a good reason not to include said patch without
reference to might-as-well-not-exist-as-far-as-we're-concerned out of
tree drivers or the similarly irrelevant wishes of nebulous corporate
entities.
--
Mathematics is the supreme nostalgia of our time.
Hi Matt,
The ball is in my court, because my wishes as a copyright holder are not
being honored.
Which is the right of Christoph because of the GPL, but it sure doesn't
help the end
users of said product.
Your claim that you are trying to "help" end users is bogus and just
plain wrong.
Period.
> As such, we make very little allowance
> for their concerns, especially when they stand in
> the way of improving things that _are_ in the kernel.
How is shipping a stripped down version of the driver, by yanking things
our customers want, improving the "things that are in the kernel"?
At any rate,
After thinking about this some more, I actually don't believe all this
will
be a problem on my end after all.
When the user installs my driver with all the extra features that our
customers
really want, I will simply check to see if jsm.ko exists, and ask the
user if I
can blow away the jsm.ko module.
So now, I think this thread can probably die a peaceful death.
Scott
On Tue, Apr 12, 2005 at 03:21:15PM -0500, Kilau, Scott wrote:
>
> However, neither IBM nor Digi wants this thread's patch to be applied,
> and yet Christoph wants to do it, completely out of spite, to break our
> out-of-tree open source driver.
>
> This is the problem that I have.
But that patch will enable the stock kernel.org kernel to work just fine
for that new device, right? What is wrong with that for all of the
thousands of users of such kernels. And if you want to provide a driver
that works with different features, there's no problem with that either.
We have numerous drivers in the stock kernel tree that work for the same
device, it's up to the distros to proper configure it in the manner they
so wish.
The patch does not "break" any other driver, they can both co-exist just
fine.
If you do object, please realize that this topic will come up again and
again and again as users try to patch the driver to work with the
device. Also realize that people can do this dynamically through sysfs
today...
thanks,
greg k-h
On Tue, Apr 12, 2005 at 04:46:10PM -0500, Kilau, Scott wrote:
> Hi Matt,
>
> The ball is in my court, because my wishes as a copyright holder are not
> being honored.
>
> Which is the right of Christoph because of the GPL, but it sure doesn't
> help the end
> users of said product.
> Your claim that you are trying to "help" end users is bogus and just
> plain wrong.
Your end users do not benefit from drivers that are not well
integrated with the kernel. If a user has to jump through hoops to
make their hardware work (including downloading extra drivers, etc.),
that is not a benefit. Case in point: the patch in question _came from
an end user_.
We've now got 12 years experience in the headaches of out of tree
drivers (binary or not) as users, developers, and distributors, and
we're sick of it. We're not supporting that approach any more, they
don't exist as far as we're concerned until they're candidates for
merger. Your hardware is no exception.
> > As such, we make very little allowance
> > for their concerns, especially when they stand in
> > the way of improving things that _are_ in the kernel.
>
> How is shipping a stripped down version of the driver, by yanking things
> our customers want, improving the "things that are in the kernel"?
End users do not benefit from bad interfaces. This may seem in
conflict with the above, but it's not. One of the main benefits of
kernel integration is that the trouble spots get sorted out and the
interfaces get cleaned up. This is good for everyone. Feel free to
resubmit those features when they're done right.
This is what your customers want, whether they know it yet or not.
Anything else is a stopgap.
> When the user installs my driver with all the extra features that our
> customers
> really want, I will simply check to see if jsm.ko exists, and ask the
> user if I
> can blow away the jsm.ko module.
And the rest of us make a note to not get Digi hardware because we're
sick of these out of tree drivers and the unspeakable hacks they
generally contain in the name of special features.
--
Mathematics is the supreme nostalgia of our time.
On Tue, 2005-04-12 11:42:31 -0500, Kilau, Scott <[email protected]>
wrote in message <[email protected]>:
> The JSM driver was forced to be stripped down when being submitted
> to the kernel sources, and many extended features removed as so to be
> included into the kernel, as the extended features added special ioctls
> and special /proc (/sys for 2.6) files.
There's a consensus that if there's *any* choice, new /proc files as
well as new ioctls shall not be introduced. So if there's management
needed (disclaimer: I don't own such a card), then this interface needs
to be introduced as a generic interface, which might be used by any
further drivers. We've just had this situation for some RAID cards,
where the vendor wanted to introduce a (specific for his devices)
interface. Either do it correct (as of best current practice), or don't
do it at all.
> > I didn't think that you would remove them. I read the posts and
> > wondered *why* they wanted the management pieces removed.
> > One reason to use the Digi products is for the sole fact that
> > they *can* be diagnosed.
> > I'm glad that Digi is still focused properly.
> > I agree that committing the drivers to the main kernel
> > is not the way to go if you are forced to remove dpa and ditty.
Well, again, if this features can only used by your hardware (and
there's proof that no other vendor will add these features *ever*), then
an own interface is okay. But if there's a possibility that a different
vendor *might* introduce these as well, then a generic interface needs
to be build (with first of all only one user: your driver).
> I will let the chips fall where they will, and clean up the mess that
> will soon be introduced into my driver world. =)
That's a plan. Good to head :-)
MfG, JBG
--
Jan-Benedict Glaw [email protected] . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
Kilau, Scott <[email protected]> wrote:
> However, neither IBM nor Digi wants this thread's patch to be applied,
> and yet Christoph wants to do it, completely out of spite, to break our
> out-of-tree open source driver.
>
> This is the problem that I have.
I think you should supply a patch that makes the in-kernel driver print a
short notice about your other driver. E.g.
----
The foo driver is a stripped-down version of the bar driver. To get the
additional configuration and diagnosis infrastructure, see the
instructions on url.
----
--
Top 100 things you don't want the sysadmin to say:
49. What's this switch for anyways...?
On Tue, 12 Apr 2005, Christoph Hellwig wrote:
>On Tue, Apr 12, 2005 at 10:30:19AM -0500, Kilau, Scott wrote:
>> However, when the copyright holder says "No, please don't add that
>> code",
>> and gives *GOOD* reasons why, you should respect that decision.
>
>You didn't not give a single good reason. Only political bullshit.
As an outside observer, I think he's given you plenty of reason to not
include this "hack". You, however, appear to only want to make a mess.
>> So if I don't sign off on this change, does the matter?
>
>No.
Could you possibly be any more of an ass? Don't bother answer that.
This is entirely the attitude the denouncers of open source live for. It
shows the complete lake of respect for the wishes of the maintainer(s). And
it's even worse because, as you and various others state, if it's not in
the kernel, it might as well not exist -- OSS, GPL, or not. So, what's the
point of maintainers submitting code for inclusion in the kernel if they are
going to be ignored the instant it's excepted? And the code's maintainer(s)
and/or authors are the only ones that *can* submit new code. On one hand
you're honoring their wishes, but then basically ignoring them the instant
they "give" you their code. (If it's already GPL'd, there's nothing legally
stopping the code from being included in the first place, so why must they
ask for and/or ok inclusion? Answer: good will within the community which
you are now pissing all over.)
Am I the only one with his eyes open here? When I read the first reply from
Scott, I was thinking, "why not just make it a config option? What's the
big f***ing deal?" Make it a config option with help text pointing people
to the "better" driver with improved features and support for that board.
Or something as simple as "don't enable this if you're going to use this
other dirver."
The mere fact that you are unwilling to accept the desires of the maintainers
subtracts substantial credability from the entire kernel development process
and stands as a powerful deterent to getting manufacturers to submit drivers
to the kernel. I'd be interested to hear Linus' take on this BS, but he's
busy digging out of the bullshit some other stuborn, self-absorbed nut has
buried him under.
--Ricky
"Kernel hacker for over 10 years" (but we know how much that's worth)
On Tue, Apr 12, 2005 at 11:27:44PM -0400, Ricky Beam wrote:
> As an outside observer, I think he's given you plenty of reason to not
> include this "hack". You, however, appear to only want to make a mess.
Why do you consider it a mess, and what reason did you see?
The jsm driver is an effort where people like Wen Xiong, Al Viro and me
put in a lot of effort to make the piece of crap the digi driver was into
something almost sane. Now we should limit it to a tiny subset of the
supported hardware just because digi is full of crack?
> This is entirely the attitude the denouncers of open source live for. It
> shows the complete lake of respect for the wishes of the maintainer(s).
While Scott wrote most of the original code that ended up in the jsm driver
he's certainly not the maintainer in any sense.
> they "give" you their code. (If it's already GPL'd, there's nothing legally
> stopping the code from being included in the first place, so why must they
> ask for and/or ok inclusion? Answer: good will within the community which
> you are now pissing all over.)
But the original code isn't technically suitable.
> Am I the only one with his eyes open here? When I read the first reply from
> Scott, I was thinking, "why not just make it a config option? What's the
> big f***ing deal?" Make it a config option with help text pointing people
> to the "better" driver with improved features and support for that board.
> Or something as simple as "don't enable this if you're going to use this
> other dirver."
Because a config option is totally pointless. If Scott wants someone to
use his driver he can that person to simply load that driver, there's
absolutely no reason for us to cripple our drivers because some vendor
has out of tree drivers. We don't remove support for card from tg3 just
because Broadcom would prefer us to use their bcm5700 driver, or remove
support for cards from the 3c59x driver just because 3com has a driver of
their own for a few of those cards.
> I think you should supply a patch that makes the in-kernel driver print a
> short notice about your other driver. E.g.
> ----
> The foo driver is a stripped-down version of the bar driver. To get the
> additional configuration and diagnosis infrastructure, see the
> instructions on url.
> ----
No. The jsm driver is one that's many bugs in the digi driver fixes and
broken interfaces stripped out. We don't want users to fall in the trap
and use the inferior digi driver.
Hi Christoph, everyone,
> While Scott wrote most of the original code that ended up in the jsm
driver
> he's certainly not the maintainer in any sense.
Christoph, au contraire.
You might want to check with Wendy again, on who the maintainer
of the JSM driver code will be. =)
At any rate, I have had enough insults from you now.
I have a workaround in place for the JSM driver conflict,
so I consider this matter closed.
Scott