[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [bluetooth-dev] Alignement fix



I reverted your changes to btdebug.h, and fixed btconfig.h
to only include the security manager stuff for us. So now
it should be ok.

//Peter

> -----Original Message-----
> From: david LIBAULT [mailto:david.libault@xxxxxxx.fr]
> Sent: 02 March 2001 11:58
> To: Peter Kjellerstedt
> Cc: bluetooth-dev@xxxxxxx.com
> Subject: Re: [bluetooth-dev] Alignement fix
> 
> 
> That was right.
> I commited the changes. 
> Can you check if you are happy with the cvs now ?
> 
> David.
> 
> Le Vendredi 02 Mars 2001 10:40, Peter Kjellerstedt a écrit :
> > > -----Original Message-----
> > > From: david LIBAULT [mailto:david.libault@xxxxxxx.fr]
> > > Sent: Friday, March 02, 2001 10:05
> > > To: Peter Kjellerstedt
> > > Cc: bluetooth-dev@xxxxxxx.com
> > > Subject: Re: [bluetooth-dev] Alignement fix
> > >
> > > I have tried to carrefully commit with your recomendations and :
> > >
> > > cvs commit: Examining linux/drivers/char/bluetooth
> > > cvs [server aborted]: "commit" requires write access to 
> the repository
> > > cvs commit: saving log message in /tmp/cvsy50Tzg
> > >
> > > Do I have write access to the repository ? (I logged in with
> > > my name dlibault and password)
> > >
> > > David.
> >
> > Hmm. My guess is that the directories you have were checked out
> > anonymously. You can check by reading the CVS/Root files in one
> > of your local directories. If it does not say dlibault@xxxxxxx.
> > at the begining of the line then it was checked out anonymously.
> > In that case you have two options, either check out a new tree
> > using:
> >
> > export CVS_RSH=ssh
> > cvs -d dlibault@xxxxxxx.net:/cvsroot/openbt 
> co apps libs
> > linux init_env Makefile
> >
> > and then move all your changed files to this new tree and commit
> > from there, or you can modify all CVS/Root files and add
> > dlibault@ to the begining of each line, which then should look
> > like:
> >
> > dlibault@xxxxxxx.net:/cvsroot/openbt
> >
> > > Le Jeudi 01 Mars 2001 18:07, Peter Kjellerstedt a écrit :
> > > > Ok, I have looked through the patch and it looks ok.
> > > >
> > > > There are a few minor details. Your local changes in
> > > > btconfig.h and btdebug.h should probably not be checked in.
> > > > Neither should the MTU change in rfcomm.c. Also it seems
> > > > that you do not have the very latest version of
> > > > apps/bluetooth/userstack (cvs would alert you about this
> > > > if you had tried to commit, so it is no big deal).
> > > >
> > > > A question: why have you added -I /usr/include to the
> > > > linux/drivers/char/bluetooth/Makefile?
> > >
> > > If not, the compiler (on my PC) complains about headers 
> not compiling
> > > properly. I don't know why I need to do that... I use 
> Mandrake 7.2.
> >
> > Ok. I believe Greg K-H already checked in a fix for this.
> >
> > > > It seems like the change in hci.h (ocf + ogf -> opcode)
> > > > and in l2cap.h are related to endianess. However, I
> > > > fail to see how hci_put_opcode() would change anything
> > > > regarding endianess compared to using th bitfields.
> > > > If it had used cpu_to_le16() I would have understood it.
> > > > Another solution would have been to change the definition
> > > > of the struct to:
> > > >
> > > > typedef struct cmd_pkt {
> > > > 	u8 type;
> > > > #ifdef __LITTLE_ENDIAN_BITFIELD
> > > > 	u16 ocf:10;
> > > > 	u16 ogf:6;
> > > > #elif __BIG_ENDIAN_BITFIELD
> > > > 	u16 ogf:6;
> > > > 	u16 ocf:10;
> > > > #else
> > > > #error "You need to define either __LITTLE_ENDIAN_BITFIELD or
> > > > __BIG_ENDIAN_BITFIELD" #endif
> > > > 	u8 len;
> > > >
> > > > 	u8 data[256];
> > > > };
> > > >
> > > > (The above code is of course totally untested.)
> > > > A solution like the one above would probably be needed to
> > > > fix all the bitfields used in rfcomm.c, sdp.c and tcs.c.
> > >
> > > 1 - this was in the Gordon's patch (that is why I did it, and
> > > believe me, changing all the hci commands was not a nice work
> > > to do...)
> > > 2 - I think this is the first step to remove the bitfields in
> > > the stack which are not a nice C feature to use (a lot of
> > > portability issues). Moreover, it doesn't improve the
> > > performance because, at the end, the processor will still have
> > > to do bit masks... so I would prefer to just use | and &, it
> > > will save everybody time and energy...
> >
> > Ok, that may be true :)
> >
> > > > I would recommend that you commit your changes in the
> > > > linux directory separately from the changes in apps as
> > > > they do not seem related.
> > > >
> > > > Start by temporarily reverting you change to the MTu in
> > > > rfcomm.c The the following commands should commit your
> > > > changes in the linux directory. After running each cvs
> > > > command you will be asked for a changelog comment.
> > > > Describe what you have done (try to keep your lines
> > > > shorter than 75 characters).
> > > >
> > > > # First update the code to be sure you have the very latest
> > > > cvs up linux
> > > > # Then proceed to commmit your changes
> > > > cvs commit linux/drivers/char/bluetooth
> > > > cd linux/include/bluetooth
> > > > cvs commit btcommon.h hci.h hci_internal.h l2cap.h rfcomm.h
> > > >
> > > > //Peter
> >
> > //Peter
> > -
> > To unsubscribe from this list: send the line "unsubscribe 
> bluetooth-dev" in
> > the body of a message to majordomo@xxxxxxx.com
> 
-
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to majordomo@xxxxxxx.com