[asterisk-dev] [Code Review]: Start the process of opaque-ifying the ast_channel by replacing direct access to the 'name' field with accessor functions.

Terry Wilson reviewboard at asterisk.org
Mon Jan 9 08:55:59 CST 2012 


> On Jan. 9, 2012, 6:13 a.m., schmidts wrote:
> > /trunk/include/asterisk/channel.h, line 773
> > <https://reviewboard.asterisk.org/r/1655/diff/2/?file=22855#file22855line773>
> >
> >     just an idea. you could let name stay here and initialise it with a warning value like "please dont use chan->name directly anymore use ast_channel_name(chan) instead". so this could help devs to fix their own apps.

The main reason I am changing the name completely is that it allows the compiler to tell us when we've messed up. I'd never catch all of the uses without it. I also want to penalize people at compile-time for using the field. Just initializing it wouldn't do much good since it would just get overwritten almost immediately anyway.


> On Jan. 9, 2012, 6:13 a.m., schmidts wrote:
> > /trunk/main/channel.c, line 1629
> > <https://reviewboard.asterisk.org/r/1655/diff/2/?file=22864#file22864line1629>
> >
> >     just a very short question about locking here. Imho it is possible that the name of the channel, given as argument, could change after this, shouldnt this channel (arg) be locked too?

arg is never a *real* channel and can't be locked. It is only passed as the address of a channel created on the stack with some fields just filled in like:

struct ast_channel tmp = {
   .name = something,
};

and I may have even gotten all of those removed in favor of searching in other ways, but I left support for the old-style just in case.


> On Jan. 9, 2012, 6:13 a.m., schmidts wrote:
> > /trunk/main/channel.c, line 1631
> > <https://reviewboard.asterisk.org/r/1655/diff/2/?file=22864#file22864line1631>
> >
> >     you could use CMP_MATCH & CMP_STOP here cause channel name should be unique imho.
> >     
> >     same on the ast_channel_by_uniqueid_cp.

the ast_channel_by_name_cb is called specifically with OBJ_MULTIPLE and we are also comparing based on length, so the match won't necessarily be unique. For example, lots of code ends up doing a search for channel names like "SIP/1234" not "SIP/1234-00000000" so that we can return all channels like SIP/1234.


> On Jan. 9, 2012, 6:13 a.m., schmidts wrote:
> > /trunk/main/channel.c, line 1674
> > <https://reviewboard.asterisk.org/r/1655/diff/2/?file=22864#file22864line1674>
> >
> >     see comment above, CMP_MATCH & CMP_STOP

I prefer to let the caller choose via flags whether or not to continue searching for other matches. If they don't specifically pass OBJ_MULTIPLE, I think CMP_MATCH implies stopping. Maybe I should specifically pass 0 for flags when ast_channel_by_uniqueid_cb is called from ast_channel_cmp_cb?


> On Jan. 9, 2012, 6:13 a.m., schmidts wrote:
> > /trunk/main/channel.c, line 1825
> > <https://reviewboard.asterisk.org/r/1655/diff/2/?file=22864#file22864line1825>
> >
> >     you should add this before the callback:
> >     
> >     if (ast_strlen_zero(name) && exten && context && (chan = ast_channel_callback....
> >     
> >     imho you would get an error message for each channel (see row 1448) if this is called with an empty name and no exten & context set. I dont know if this even could happen but row 1590 looks like it could be.

This would change the logic so that it would be possible to then call the by_name callback with a zero-length name if, for instance, name and exten were both null. So it would just push the error to a different function. I'm pretty sure that it is an actual bug in the calling code if this ever happens and I would rather warn people about it than just hide it by throwing in checks for the values just to avoid getting an error message. In fact, I'm even considering putting in ast_assert() calls here so that in dev mode it would die if we did this.

Can you think of a reason this would be a bad thing to do? I've been staring at the code for a while and may have tunnel vision.


On Jan. 9, 2012, 6:13 a.m., Terry Wilson wrote:
> > fine work and a good way to go.

Thanks!


- Terry


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1655/#review5133
-----------------------------------------------------------


On Jan. 6, 2012, 3:51 p.m., Terry Wilson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1655/
> -----------------------------------------------------------
> 
> (Updated Jan. 6, 2012, 3:51 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> There would be many benefits to making the ast_channel an opaque handle, from increasing maintainability to presenting ways to kill masquerades. I propose that we kick things off by taking things a field at a time, renaming the field to '__do_not_use_${fieldname}' and then writing setters/getters and converting the existing code to using them. When all fields are done, we can move ast_channel to a C file from channel.h and lop off the '__do_not_use_'.
> 
> This patch sets up main/channel_interal_api.c to be the only file that actually accesses the ast_channel's fields directly. The intent would be for any API functions in channel.c to use the accessor functions. No more monkeying around with channel internals. We should use our own APIs.
> 
> The interesting changes in this patch are the addition of channel_internal_api.c, the moving of the AST_DATA stuff from channel.c to channel_internal_api.c (note: the AST_DATA stuff will have to be reworked to use accessor functions when ast_channel is really opaque), and some re-working of the way channel iterators/callbacks are handled so as to avoid creating fake ast_channels on the stack to pass in matching data by directly accessing fields (since "name" is a stringfield and the fake channel doesn't init the stringfields, you can't use the ast_channel_name_set() function). I went with ast_channel_name(chan) for a getter, and ast_channel_name_set(chan, name) for a setter.
> 
> Ideas welcome!
> 
> The majority of the grunt-work for this change was done by writing a semantic patch using Coccinelle ( http://coccinelle.lip6.fr/ ).
> 
> note: There are some extra changes to some of the h323 files to comment out variables that were set and not used so that I could get it to compile under dev-mode.
> 
> 
> Diffs
> -----
> 
>   /trunk/addons/chan_mobile.c 349871 
>   /trunk/addons/chan_ooh323.c 349871 
>   /trunk/addons/ooh323c/src/memheap.c 349871 
>   /trunk/apps/app_adsiprog.c 349871 
>   /trunk/apps/app_alarmreceiver.c 349871 
>   /trunk/apps/app_amd.c 349871 
>   /trunk/apps/app_chanisavail.c 349871 
>   /trunk/apps/app_chanspy.c 349871 
>   /trunk/apps/app_confbridge.c 349871 
>   /trunk/apps/app_dahdibarge.c 349871 
>   /trunk/apps/app_dahdiras.c 349871 
>   /trunk/apps/app_dial.c 349871 
>   /trunk/apps/app_directed_pickup.c 349871 
>   /trunk/apps/app_disa.c 349871 
>   /trunk/apps/app_dumpchan.c 349871 
>   /trunk/apps/app_externalivr.c 349871 
>   /trunk/apps/app_fax.c 349871 
>   /trunk/apps/app_flash.c 349871 
>   /trunk/apps/app_followme.c 349871 
>   /trunk/apps/app_getcpeid.c 349871 
>   /trunk/apps/app_jack.c 349871 
>   /trunk/apps/app_macro.c 349871 
>   /trunk/apps/app_meetme.c 349871 
>   /trunk/apps/app_milliwatt.c 349871 
>   /trunk/apps/app_minivm.c 349871 
>   /trunk/apps/app_mixmonitor.c 349871 
>   /trunk/apps/app_page.c 349871 
>   /trunk/apps/app_parkandannounce.c 349871 
>   /trunk/apps/app_playback.c 349871 
>   /trunk/apps/app_queue.c 349871 
>   /trunk/apps/app_readexten.c 349871 
>   /trunk/apps/app_record.c 349871 
>   /trunk/apps/app_rpt.c 349871 
>   /trunk/apps/app_sms.c 349871 
>   /trunk/apps/app_softhangup.c 349871 
>   /trunk/apps/app_stack.c 349871 
>   /trunk/apps/app_talkdetect.c 349871 
>   /trunk/apps/app_test.c 349871 
>   /trunk/apps/app_voicemail.c 349871 
>   /trunk/apps/app_waitforsilence.c 349871 
>   /trunk/bridges/bridge_multiplexed.c 349871 
>   /trunk/channels/chan_agent.c 349871 
>   /trunk/channels/chan_alsa.c 349871 
>   /trunk/channels/chan_console.c 349871 
>   /trunk/channels/chan_dahdi.c 349871 
>   /trunk/channels/chan_gtalk.c 349871 
>   /trunk/channels/chan_h323.c 349871 
>   /trunk/channels/chan_iax2.c 349871 
>   /trunk/channels/chan_jingle.c 349871 
>   /trunk/channels/chan_local.c 349871 
>   /trunk/channels/chan_mgcp.c 349871 
>   /trunk/channels/chan_misdn.c 349871 
>   /trunk/channels/chan_nbs.c 349871 
>   /trunk/channels/chan_oss.c 349871 
>   /trunk/channels/chan_phone.c 349871 
>   /trunk/channels/chan_sip.c 349871 
>   /trunk/channels/chan_skinny.c 349871 
>   /trunk/channels/chan_unistim.c 349871 
>   /trunk/channels/chan_usbradio.c 349871 
>   /trunk/channels/chan_vpb.cc 349871 
>   /trunk/channels/console_video.c 349871 
>   /trunk/channels/sig_analog.c 349871 
>   /trunk/channels/sig_pri.c 349871 
>   /trunk/channels/sig_ss7.c 349871 
>   /trunk/funcs/func_audiohookinherit.c 349871 
>   /trunk/funcs/func_channel.c 349871 
>   /trunk/funcs/func_frame_trace.c 349871 
>   /trunk/funcs/func_global.c 349871 
>   /trunk/funcs/func_groupcount.c 349871 
>   /trunk/funcs/func_lock.c 349871 
>   /trunk/include/asterisk/channel.h 349871 
>   /trunk/main/abstract_jb.c 349871 
>   /trunk/main/aoc.c 349871 
>   /trunk/main/app.c 349871 
>   /trunk/main/autochan.c 349871 
>   /trunk/main/bridging.c 349871 
>   /trunk/main/ccss.c 349871 
>   /trunk/main/cdr.c 349871 
>   /trunk/main/cel.c 349871 
>   /trunk/main/channel.c 349871 
>   /trunk/main/channel_internal_api.c PRE-CREATION 
>   /trunk/main/cli.c 349871 
>   /trunk/main/dial.c 349871 
>   /trunk/main/dsp.c 349871 
>   /trunk/main/features.c 349871 
>   /trunk/main/file.c 349871 
>   /trunk/main/indications.c 349871 
>   /trunk/main/manager.c 349871 
>   /trunk/main/pbx.c 349871 
>   /trunk/main/rtp_engine.c 349871 
>   /trunk/main/say.c 349871 
>   /trunk/main/udptl.c 349871 
>   /trunk/pbx/pbx_dundi.c 349871 
>   /trunk/pbx/pbx_lua.c 349871 
>   /trunk/pbx/pbx_realtime.c 349871 
>   /trunk/res/res_adsi.c 349871 
>   /trunk/res/res_agi.c 349871 
>   /trunk/res/res_calendar.c 349871 
>   /trunk/res/res_fax.c 349871 
>   /trunk/res/res_jabber.c 349871 
>   /trunk/res/res_monitor.c 349871 
>   /trunk/res/res_musiconhold.c 349871 
>   /trunk/res/res_mutestream.c 349871 
>   /trunk/res/snmp/agent.c 349871 
> 
> Diff: https://reviewboard.asterisk.org/r/1655/diff
> 
> 
> Testing
> -------
> 
> I ran it through the testsuite and seemed to get the same number of failures that I got without it. I also made some calls and tested out 'core show channel <tab>' and 'core show channel Console/dsp', and core show channels to make sure that the changes to the iterators seemed to work.
> 
> 
> Thanks,
> 
> Terry
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20120109/206e2368/attachment-0001.htm>

More information about the asterisk-dev mailing list