Hello all,
This is the last patch from Krzystof Halasa for the Generic HDLC layer
plus some changes to adapt dscc4.c (maintained by Fran?ois Romieu) to
it.
It was done against kernel 2.4.17-pre8, and fixes the HDLC Layer that is
currently in the kernel, which uses almost all of the device IOCTL
range.
I am waiting for the inclusion of these changes in the kernel for months
to submmit the PC300 driver, and this delay is causing me troubles,
customers complainings, etc.
Please take a look at the patch, and check if everything is ok. If you
all agree, I will submmit it on December 20th.
Best regards,
Daniela
Daniela Squassoni <[email protected]> :
[...]
> Please take a look at the patch, and check if everything is ok. If you
> all agree, I will submmit it on December 20th.
It looks correct for the dscc4 part. I'll try it at home.
I'm not sure we're supposed to change the api in 2.4 though.
--
Ueimor
On Fri, Dec 14, Daniela Squassoni wrote:
> Hello all,
>
> This is the last patch from Krzystof Halasa for the Generic HDLC layer
> plus some changes to adapt dscc4.c (maintained by Fran?ois Romieu) to
> it.
I'm confused. How was the patch generated ? How should I apply it ?
The patch repeats some of Krzystofs changes so I can't apply it over the
top of his patch but at the same time it doesn't include the changes for
FarSite, SBE Inc or you own Cyclades cards. Better to have a patch that
brings all the drivers up to spec in one hit surely.
Probably too late to get API changes into 2.4.x, but we should get the
generic HDLC layer into 2.5.x ASAP IMHO. Then you might be able to argue
for a backport into 2.4.x in the future.
> I am waiting for the inclusion of these changes in the kernel for months
> to submmit the PC300 driver, and this delay is causing me troubles,
> customers complainings, etc.
Tell me about it :-) FarSite are having to maintain an extra set of patches
for customers who need the functionality of the generic layer.
ps. I'm no longer working for FarSite the lure of embeded Linux and video
was too much :-) so these comments are mine not theirs.
--
Bob Dunlop
Bob Dunlop wrote:
>
> I'm confused. How was the patch generated ? How should I apply it ?
>
> The patch repeats some of Krzystofs changes so I can't apply it over the
> top of his patch but at the same time it doesn't include the changes for
> FarSite, SBE Inc or you own Cyclades cards. Better to have a patch that
> brings all the drivers up to spec in one hit surely.
This patch was done against the kernel 2.4.17-pre8. All the drivers that
are using the HDLC layer in the kernel source tree have been included.
The farsync.c does not even call the register_hdlc_device routine...
Let's fix what is already in the kernel source tree first, and then we
can include what is missing (e.g. the PC300 driver and others that
provide separate patches for the HDLC layer), right?!
>
> Probably too late to get API changes into 2.4.x, but we should get the
> generic HDLC layer into 2.5.x ASAP IMHO. Then you might be able to argue
> for a backport into 2.4.x in the future.
Why doing that if it is ready for 2.4.x?!
The patch that I've just sent doesn't bring anything really new. It just
fixes what is wrong in the current version. Am I missing something here?
>
> > I am waiting for the inclusion of these changes in the kernel for months
> > to submmit the PC300 driver, and this delay is causing me troubles,
> > customers complainings, etc.
>
> Tell me about it :-) FarSite are having to maintain an extra set of patches
> for customers who need the functionality of the generic layer.
That is exactly what I have to do...
Best regards,
Daniela
Bob Dunlop <[email protected]> writes:
> The patch repeats some of Krzystofs changes so I can't apply it over the
> top of his patch but at the same time it doesn't include the changes for
> FarSite, SBE Inc or you own Cyclades cards. Better to have a patch that
> brings all the drivers up to spec in one hit surely.
Forget wanxl, it's not yet ready. Forget pc300too, I'm probably going
to keep it outside the main kernel.
Anyway, incremental patch is better, I'm going to submit my paches
to 2.5 after some features (FR InARP, DCD handling, probably FR bridging)
are added and tested.
> Probably too late to get API changes into 2.4.x, but we should get the
> generic HDLC layer into 2.5.x ASAP IMHO. Then you might be able to argue
> for a backport into 2.4.x in the future.
Seems it's better to include that things in 2.4 when it works fine.
Especially if all drivers are updated.
2.5 first - of course.
--
Krzysztof Halasa
Network Administrator
Krzysztof Halasa wrote:
>
> Anyway, incremental patch is better, I'm going to submit my paches
> to 2.5 after some features (FR InARP, DCD handling, probably FR bridging)
> are added and tested.
>
> Seems it's better to include that things in 2.4 when it works fine.
> Especially if all drivers are updated.
> 2.5 first - of course.
How long do you think it will take to include the last changes in 2.4?
Isn't it possible to submit a patch without these new features, just to
speed up this process? Is there anything else that still need to be done
before you submit it?
It seems that there is a consensus that maintaining this out of the
kernel is causing some overhead to the drivers maintainers...
Best regards,
Daniela