Menu
▾
▴
Re: [Lksctp-developers] Binding to multiple IP addresses from different families
|
From: La M. H.P. Y. <pi...@ti...> - 2004-10-29 13:50:19
|
It won't work at all for PPC or other architectures. Anatoly Khusid wrote: >We have this trick working for IP sockets in Kernel. It's 2.4 Kernel.. Are >you saying that it might not work for newer kernel versions? > > > >>old_fs = get_fs(); >>set_fs(get_ds()); >>sock_sendmsg(sock, &msg, size); >>set_fs(old_fs); >> >> > > > >-----Original Message----- >From: lks...@li... >[mailto:lks...@li...]On Behalf Of La >Monte H.P. Yarroll >Sent: Friday, October 29, 2004 9:32 AM >To: Anatoly Khusid >Cc: 'Sridhar Samudrala'; 'Vlad Yasevich'; >lks...@li... >Subject: Re: [Lksctp-developers] Binding to multiple IP addresses from >different families > > >That's not the least bit portable. > >Anatoly Khusid wrote: > > > >>Wouldn't something like that work (to avoid the copu from user to kernel) >> /* >> * Comment from Usenet: >> * >> * Re: get_fs() and set_fs() mm_segment_t >> * From: Bogdan Diaconescu (bo...@de...) >> * Date: Wed Nov 07 2001 - 16:09:23 EST >> * >> * Hi, >> * On x86 platforms Linux uses FS register to keep the data segment >> * register with which access user segment register. If a sys_call >> * is made and the kernel needs to copy data from user space then >> * FS will have the value USER_DS. Many kernel functions copy >> * or return data from/to user space. In order to use the same >> * functions to copy/return data from/to kernel space you need to >> * do the followings: >> * mm_segment_t* old_fs; >> * old_fs = get_fs(); >> * set_fs(KERNEL_DS); >> * call the kernel functions >> >>So we could do this: >> >>old_fs = get_fs(); >>set_fs(get_ds()); >>sock_sendmsg(sock, &msg, size); >>set_fs(old_fs); >> >> >> >> >>-----Original Message----- >>From: Sridhar Samudrala [mailto:sr...@us...] >>Sent: Friday, October 29, 2004 2:34 AM >>To: Anatoly Khusid >>Cc: 'La Monte H.P. Yarroll'; 'Vlad Yasevich'; >>lks...@li... >>Subject: RE: [Lksctp-developers] Binding to multiple IP addresses from >>different families >> >> >>On Thu, 28 Oct 2004, Anatoly Khusid wrote: >> >> >> >> >> >>>>Anatoly, may I suggest that you put together a file to hold the >>>> >>>> >>>> >>>> >>>intra-kernel >>> >>> >>> >>> >>>>API for LKSCTP? Even if functions in this file are nothing more than >>>> >>>> >>>> >>>> >>direct >> >> >> >> >>>>calls to existing code, it is still useful to gather the whole interface >>>> >>>> >>>> >>>> >>in >> >> >> >> >>>>one place and make it very explicit. Is there an existing naming >>>> >>>> >>>> >>>> >>convention >> >> >> >> >>>>for identifying this kind of symbol which is intended for export to other >>>>parts of the kernel? I imagine something like sctp_api_*... >>>> >>>> >>>>As Sridhar suggests, it may be useful to restructure some of the existing >>>>code so make it easier to call from sockets.c and from your wrapper >>>>functions. >>>> >>>> >>>> >>>> >>Actually, i was suggesting Anatoly to override the real >>copy_from_user()/getuser() >>etc in his module with stubs that may even avoid the copy. >>The only reason the interfaces in sctp/socket.c cannot be called from >> >> >within > > >>kernel is because of the calls to these user<->kernel copies. If you can >>override these routines, i think it should be possible to use the existing >>sctp >>interfaces. >> >>When SCTP was designed, i think we followed the model of existing transport >>protocols and didn't expect any need to support in-kernel user. >> >> >> >> >> >>>Having a well defined SCTP Kernel interface is an excellent idea! Solaris >>>has done this for their version of a native SCTP, and let me tell you, its >>>extremely good. >>>If Linux wants to stay competitive with Sun, then a concise and a well >>>documented SCTP kernel interface is a must. >>>The biggest issues dealing with SCTP in kernel is that we don't really >>> >>> >>> >>> >>have >> >> >> >> >>>a good way of handling the asynchronous I/O. >>>For example, in a good kernel interface, nothing should block. Instead, >>> >>> >>> >>> >>the >> >> >> >> >>>user would specifiy the call back routines which will get called when >>>certain things happen (for example, when accept() finally can give you a >>> >>> >>> >>> >>new >> >> >> >> >>>association). Sure, you can deal with blocking calls in Kernel, but this >>> >>> >>> >>> >>is >> >> >> >> >>>a pain! >>>Another issue with the recvmsg(), I belive it copies data into a user >>>supplied buffer. Instead, it should give you a pointer to sk_buff to >>> >>> >>> >>> >>avoid >> >> >> >> >>>any mem. copies. >>>I can throw together a kernel interface that I think is appropriate, but >>> >>> >>> >>> >>who >> >> >> >> >>>is going to implement it ? :-) >>> >>> >>> >>> >>The requirement for this in-kernel API is coming from you and hence you are >>the >>right person to implement it. >> >>Thanks >>Sridhar >> >> >> -- Anyone who quotes me in their sig is an idiot. -- Rusty Russell's sig |