>
> Remove some remaining vestiges of the old hacks jsm had to work around
> the old tty buffering. With the new tty buffering it simply doesn't
> matter any more.
>
> Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
Thanks Alan for helping cleaning up jsm.
Acked-by: Scott Kilau <[EMAIL PROTECTED]>
Remove some remaining vestiges of the old hacks jsm had to work around
the old tty buffering. With the new tty buffering it simply doesn't
matter any more.
Signed-off-by: Alan Cox [EMAIL PROTECTED]
Thanks Alan for helping cleaning up jsm.
Acked-by: Scott Kilau [EMAIL PROTECTED]
-
To
Hi all,
> Last time I poked at the tools they were working under 2.6 with some
> trivial compile fixes. Ideally this driver would be trimmed
> to ISA only
> and the newer dgrs drivers merged but latter half appears to
> be something
> digi have no interest in
I would be very surprised if
Hi all,
Last time I poked at the tools they were working under 2.6 with some
trivial compile fixes. Ideally this driver would be trimmed
to ISA only
and the newer dgrs drivers merged but latter half appears to
be something
digi have no interest in
I would be very surprised if anyone
> > > > > So we have a file that's closed although open() never
succeeded?
> > > >
> > > > That's correct! It's been a pain in my butt for years.
> > >
> > > How did you deal with that proctological issue?
> >
> > Just make sure the close() handles the situation properly. It makes
> > reference
So we have a file that's closed although open() never
succeeded?
That's correct! It's been a pain in my butt for years.
How did you deal with that proctological issue?
Just make sure the close() handles the situation properly. It makes
reference counting... fun.
Hi Al,
> What was your binutils version (# ld -v) before and after the upgrade?
I was on the "last" version of binutils that Red Hat 9 had, which was:
binutils-2.13.90.0.18-9.i386
I went up to the prebuilt version of binutils from Fedora Core 3:
[EMAIL PROTECTED] tmp]# ld -v
GNU ld version
Hi all,
> > objcopy: arch/i386/boot/compressed/vmlinux.bin: File truncated
> > make[2]: *** [arch/i386/boot/compressed/vmlinux.bin] Error 1
> > make[1]: *** [arch/i386/boot/compressed/vmlinux] Error 2
> > make: *** [bzlilo] Error 2
I got the same as well here on my box.
I am using Red Hat 9,
Hi all,
objcopy: arch/i386/boot/compressed/vmlinux.bin: File truncated
make[2]: *** [arch/i386/boot/compressed/vmlinux.bin] Error 1
make[1]: *** [arch/i386/boot/compressed/vmlinux] Error 2
make: *** [bzlilo] Error 2
I got the same as well here on my box.
I am using Red Hat 9, with a lot
Hi Al,
What was your binutils version (# ld -v) before and after the upgrade?
I was on the last version of binutils that Red Hat 9 had, which was:
binutils-2.13.90.0.18-9.i386
I went up to the prebuilt version of binutils from Fedora Core 3:
[EMAIL PROTECTED] tmp]# ld -v
GNU ld version
Hi Len,
> I am seeing a very strange problem which seems to be in the tty layer.
>
> I am using an exar 17D154 based PCI card (like the digi neo style
card)
> using the jsm driver. Kernel version 2.6.16.25.
There are a couple interesting things I would do here.
1) The tty "flip" buffer stuff
Hi Len,
I am seeing a very strange problem which seems to be in the tty layer.
I am using an exar 17D154 based PCI card (like the digi neo style
card)
using the jsm driver. Kernel version 2.6.16.25.
There are a couple interesting things I would do here.
1) The tty flip buffer stuff was
Hi everyone,
> As I understand it a small number of such devices were produced, but I
> have no objection to it going away. Even if someone had such a card it
> would not actually be useful any more.
> Alan
Alan is correct.
The "Digi RightSwitch" product did actually make it out to the real
Hi everyone,
As I understand it a small number of such devices were produced, but I
have no objection to it going away. Even if someone had such a card it
would not actually be useful any more.
Alan
Alan is correct.
The Digi RightSwitch product did actually make it out to the real
world.
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
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
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.
nux/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
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
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
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
> 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
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
?
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]; linux-kernel@vger.kernel.org
Subject: Re: Digi Neo 8: linux-2.6.12_r2 jsm driver
On Tue, Apr 12, 2005 at 09
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]; linux-kernel@vger.kernel.org
Subject: Digi Neo 8: linux-2.6.12_r2 jsm driver
-BEGIN PGP SIGNED
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]; linux-kernel@vger.kernel.org
Subject: Digi Neo 8: linux-2.6.12_r2 jsm driver
-BEGIN PGP SIGNED
?
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]; linux-kernel@vger.kernel.org
Subject: Re: Digi Neo 8: linux-2.6.12_r2 jsm driver
On Tue, Apr 12, 2005 at 09
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
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
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
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
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
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.
Thanks Adrian for helping clean up the driver.
Wendy will integrate your patch into our source tree.
Scott
From: Adrian Bunk [mailto:[EMAIL PROTECTED]
Sent: Sat 4/9/2005 1:04 PM
To: Andrew Morton
Cc: Kilau, Scott; linux-kernel@vger.kernel.org
Subject: [2.6
Thanks Adrian for helping clean up the driver.
Wendy will integrate your patch into our source tree.
Scott
From: Adrian Bunk [mailto:[EMAIL PROTECTED]
Sent: Sat 4/9/2005 1:04 PM
To: Andrew Morton
Cc: Kilau, Scott; linux-kernel@vger.kernel.org
Subject: [2.6
> Wouldn't you think the kernel already takers are of flow control,
given
> that it already handles the sending of the X* characters?
Hi Russell,
Yes.
The code was written by me before it was integrated into "serial core".
Like your comments suggest, a lot of the "tty" code is now
Wouldn't you think the kernel already takers are of flow control,
given
that it already handles the sending of the X* characters?
Hi Russell,
Yes.
The code was written by me before it was integrated into serial core.
Like your comments suggest, a lot of the tty code is now duplicated
> > DPA support is a requirement for all Digi drivers, so it would
> > not be possible for me to remove them from my "dgnc" version
> > of the driver.
> "requirement" from whom and to who? The Linux kernel community?
>From our customers who are moving from other OS's to Linux,
and expect DPA
2005 11:32 AM
To: Greg KH
Cc: Kilau, Scott; linux-kernel@vger.kernel.org
Subject: Re: [ patch 6/7] drivers/serial/jsm: new serial device driver
Greg KH wrote:
>On Wed, Mar 09, 2005 at 10:50:04AM -0500, Wen Xiong wrote:
>
>
>>+/* Ioctls needed for dpa operation */
Cc: Kilau, Scott; linux-kernel@vger.kernel.org
Subject: Re: [ patch 6/7] drivers/serial/jsm: new serial device driver
Greg KH wrote:
On Wed, Mar 09, 2005 at 10:50:04AM -0500, Wen Xiong wrote:
+/* Ioctls needed for dpa operation */
+#define DIGI_GETDD ('d'8) | 248 /* get driver info
DPA support is a requirement for all Digi drivers, so it would
not be possible for me to remove them from my dgnc version
of the driver.
requirement from whom and to who? The Linux kernel community?
From our customers who are moving from other OS's to Linux,
and expect DPA support to be
> >
> > If you were to open up the port with an "stty -a" to get the current
> > settings and signals, you would unintentionally raise RTS and DTR.
>
> Why not fix the driver to not change the current line settings if it
is
> not being opened for the first time? That seems like a much simpler
> Who needs to know if a port is open or not?
>
>
> +static ssize_t jsm_tty_baud_show(struct class_device *class_dev, char
*buf)
> No, please delete these, and the other sysfs files that duplicate the
> same info that you can get by using the standard Linux termios calls.
> There is no need for
Who needs to know if a port is open or not?
snipped some code
+static ssize_t jsm_tty_baud_show(struct class_device *class_dev, char
*buf)
No, please delete these, and the other sysfs files that duplicate the
same info that you can get by using the standard Linux termios calls.
There is
If you were to open up the port with an stty -a to get the current
settings and signals, you would unintentionally raise RTS and DTR.
Why not fix the driver to not change the current line settings if it
is
not being opened for the first time? That seems like a much simpler
way
to
45 matches
Mail list logo
