Re: bluetooth 6lowpan interfaces are not virtual anymore

[Michael Richardson <mcr@sandelman.ca>]

[-- Attachment #1: Type: text/plain, Size: 1530 bytes --]


Alexander Aring <aar@pengutronix.de> wrote:
    >> In a classic SVR4 STREAMS works, it would have been just another
    >> module.  (No, I'm not a fan of *STREAMS* or of SVR4 in general,
    >> although I liked some of the ideas).
    >>

    > ok, I see you complain about "having a virtual on top of wpan
    > interface", or?

    > I wanted to talk at first about the queue handling which is introduced
    > when 6LoWPAN is not a virtual interface anymore. Or do you want to have
    > a queue in front of 6lowpan adaptation (see other mail reply with ASCII
    > graphics).

I would like to have a single queue, as close to the hardware as possible,
such that BQL can do it's thing easily.  Should we rethink outgoing fragment
handling for 6lowpan?  Clearly the BT people had a need.
I don't think they've had a chance to respond to your complaints.

    > We can change that you can run multiple interfaces on one
    > PHY. Currently we just allow one, because address filtering. Disable
    > address filtering
    > we will loose ACK handling on hardware.

Yes, that's a limitation of some hardware, and if you enable multiple PANIDs,
that might be the consequence....

    > I can try to implement all stuff in software "for fun, maybe see what
    > we can do to handle ACK in software, etc" Then you can run multiple

I'm not asking you to do it, I'm asking, now that we've gotten to a certain
point, we have a better idea what the various requirements are, and can we
re-evaluate things and maybe tweak some things.