[Prism54-devel] [PATCH] islpci_close() should shut down the radio

Aurelien slts@free.fr
Mon, 5 Jan 2004 16:28:46 +0100


Hello,

On Mon, 05 Jan 2004 00:35:21 +0100
Jens Maurer <Jens.Maurer@gmx.net> wrote:

> Hello!
> 
> It has bothered me that after a "ifconfig eth1 down" my card was
> not totally inert, but still had the green light ("link to AP established")
> turned on, i.e. the radio and the firmware was still active.

Yep it was on my todo list and is related to bug#28. Thanks, for your help. Now debug your code ! ;-)


> Btw, the recent changes to isl_ioctl.c are good, except
> that it's now time to get rid of the MGT_* macros,
> because they don't really save lines of code any more
> and sometimes contain "return" statements that
> obfuscate the program flow when used (hopefully no
> user holds any locks when using these).

Well, I still think the MGT_* macros save some lines of code :
	1)On get request : if you don't want to return on error, you must check that the call was successfull, and at at the end return succes if all get requests were sucessfull, it will be dirty. Moreover if the call is not successfull, you can end with NULL pointers (this can be worked around by allocating some dummy object in this case, or making the mib 'universal').
	2)On set request : you still have the problem with return value. And why would we want to continue setting subsequent oids if the first fails ? (This could hang the card if it was not already)

Of course in a perfect world, all set/get requests will succeed but can we make this assumption ? We could even make them always successful by returning dummy values.

The execution flow is maybe strange at first sight, but if you're careful everything can run well.

> hopefully no user holds any locks when using these.

You're surprised ? Do we look so stupid ?
Their might still be some error with this strange execution flow, but we try to be carefull with this kind of error.

We may redesign all this shit if we ever redesign queue management.

	...And justice for all