Dag wrote :
> Hi Jean!
>
> OK, I've looked through your patch, and I have applied some of it. But I
> decided to do things a bit different:
>
> o I see no reason to support Ultra PID's with extension bytes. There will
> _never_ be any use for it! IrDA have reserved all pid's and they have only
> specified one (0x01 for Ultra). This mechanism is the same as for hint
> bytes, and nobody supports more than 2 hint bytes!!! Therefore I have
> choosen not to use your irda_ultra_bind() function.
With all due respect, this is really a stupid decision. This
functionality was working (as opposed to your patches) and was
conformant to the spec, and there is absolutely no reason to remove
it. You limit the number of protocols on top of Ultra to 127, which is
not much (we don't have dynamic allocation here). If I follow your
reasoning, let's remove Ultra because nobody will _never_ use it.
> o I have also moved the PID byte from af_irda.c down to irlmp.c. So now you
> can open as many connless LSAP's as you want, and IrLMP will demultiplex
> based on the pid! The only reason to not have only one connless LSAP and do
> refcounting, is that we need to have different callbacks to the different
> sockets opening the connless LSAP. I know this is incorrect (in theory),
> but again. The connectionless LSAP will only be used by Ultra!! No need
> to support anything else, at least not in the main distribution! Making a
> separate Ultra layer is out of the question ;-)
This was exactly what I was proposing (see my comments in the
code) and I had started to do.
> o No support for connectionless LSAPs with selectors other than 0x70. The
> spec says this is the _only_ connless LSAP, and that we should drop all
> frames containing higher selectors. If we have support for this, the we
> might fail a compliance test, so again this will not go into the main
> distribution.
I just hope you didn't hardcoded 0x70 all over the place. My
code was careful to strike a balance between compliance to the spec
and future extensibility.
> o IrLAP now sets the conn addr to broadcast whenever it goes into NDM,
> which makes it simpler to send out correct UI frames. Remember that you
> cannot send out UI frames using the broadcast address while a connection is
> running, so the use of SEND_I_FRAME and SEND_UI_FRAME is good enough as is.
Whatever.
> Hope you don't get really mad at me, but I think this is the best to
> do. This will give us a good Ultra functionality and an impl. which is easy
> to debug (and that is usually my job ;-)
Currently, I feel that's it's me doing most of the debugging
and correcting your mistakes in the code.
> If you feel I'm destroying
> everything, then please tell me since I really want you to continue
> torturing and extending the Linux-IrDA stack. You're doing a really great
> job!!
Try to read a bit more carefully patches, comments and so on,
and try to understand what the patch is doing instead of seeing it
only the way you feel.
> -- Dag
Jean
_______________________________________________
Linux-IrDA mailing list - [EMAIL PROTECTED]
http://www4.pasta.cs.UiT.No/mailman/listinfo/linux-irda
