This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Config keys


David Marqvar (DAM) wrote:
Hi,

Is there any good reason that the config keys for serial devices are
serial-specific, e.g.:

#define CYG_IO_GET_CONFIG_SERIAL_INPUT_FLUSH 0x0104

could be defined as:

#define CYG_IO_GET_CONFIG_SERIAL_INPUT_FLUSH
CYG_IO_GET_CONFIG_INPUT_FLUSH

and the generic part should then be expanded with
// ======== 0x1000 Generic
===================================================
// Get/Set configuration 'key' values that can apply to more than one
// class of device.
#define CYG_IO_GET_CONFIG_INPUT_FLUSH           0x1104

... and so on.

This would allow different serial-alike devices to be handled in a common
way by upper layer applications.

In our development we both have serial devices as UART and USB (acting as a
serial device). Others may come, for example serial Bluetooth...

I can file a patch.... :-)

A patch always helps :-). I'd be sympathetic, although fairly obviously this is part of the API so the existing macro name needs to be kept as well.


But there's still an issue since not everything is right with this anyway... why should something associated with getting a config do an input flush, or really do _anything_? "Getting" something should be a passive operation and not change the system. Well, we can't change the serial drivers easily now, but we should get it right for any new extensions.

Arguably there is a need for some other function (dare I mention the dread name "ioctl"?) which deals with other driver-specific operations.

But since I don't like the thought of an extra function pointer, I'd probably just go with something like CYG_IO_SET_CONFIG_INPUT_FLUSH and add something in the serial_set_config to chain to serial_get_config for this particular value.

(Plus of course there's no easy way for new packages to extend the config keys but there's no point worrying about that until eCos v3.0 ;-).)

Jifl
--
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine


-- Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos and search the list archive: http://sources.redhat.com/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]