public inbox for
 help / color / mirror / Atom feed
From: Frank Pagliughi <>
To: "Bernard Fouché" <>
Subject: Re: Closing devices
Date: Thu, 21 Jun 2012 18:20:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

>> In this context - closable devices - it seems unfortunate that the 
>> lookup() function has the side effect of opening the device. I can 
>> imagine that some code might just be trying to get the devtab entry 
>> for other purposes. Perhaps there needs to be another search function 
>> that returns the entry without triggering the lookup() function?
> The problem seems yet more general: anything can call cyg_io_lookup() 
> and since the API doesn't have from the beginning a function call to 
> report 'I don't need the devtab entry anymore', then even counting the 
> number of times lookup() is called won't help much: my suggestion do 
> move hw init code from init() to lookup() is very wrong...

Well, several device drivers do postpone "final" initialization until 
the lookup() function. But many more don't make a distinction at all.

>> Does the file I/O code serialize calls to lookup?  I examined a few 
>> device drivers the implement lookup() and don't see any explicit 
>> mechanism to prevent race conditions, but that could be due to the 
>> nature of the calls not requiring it. I suppose the drivers should 
>> lock the scheduler when manipulating this new reference count.
> Since when calling lookup() you mostly only get a reference to the 
> devtab entry, there isn't any race condition. If you look at 
> ser_16x5x.c, when lookup() is called, it calls serial_init() in the 
> upper layer, in serial.c . In serial.c, the concerned channel is 
> initialized only once by serial_init(), for whatever lower driver 
> calls it. I guess this has been done to allow calling lookup() at any 
> time, multiple times.

Sorry. I meant the individual implementations of lookup() calls in the 
drivers that do use it. I didn't see any that locked the scheduler 
before they started fiddling with registers on the device. Though 
admittedly, I didn't look through too many drivers.

> Well my callback scheme seems all wrong: the more I look, the more it 
> seems that nothing is able to track down exactly the hw driver use 
> made by upper layers (packages or application code). Since the 
> application needs to handle many details like GPIO pin setup, then it 
> can also mask the interrupt ;-). So much for a layered software model 
> with low level stuff done only in low level code...

I just want to reiterate that I am trying to find a mechanism by which I 
can add the capability to write *new* drivers that can close their 
devices, without breaking the existing code.

So all the drivers that already exist would work in the exact same way - 
they are fully opened after init() and the first call to lookup(), and 
they never close.

But if you want to write new drivers that can be closed, or modify 
select ones that are already written than there is a mechanism to do so, 
even if there are some constraints on using these new devices.  For 
example, if multiple threads are using a device and one thread calls the 
yet-to-be-implemented cyg_io_shutdown() funtion, obviously the device 
would be closed for all the threads.

New applications that make use of the device "close" feature would need 
to be conscious of this and properly protect and share the closable objects.

It's just maddening to me that when you use the File IO layer, and you 
call close(fd) on your device, nothing gets propogated to the driver and 
it still keeps chugging away, servicing interrupts, and consuming CPU 
time and electric power, even though the application thought that it 
"closed" the device.

Does that make sense?


  reply	other threads:[~2012-06-21 18:20 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-12 12:34 Handling RTS with an UART that doesn't directly drives the RTS pin Bernard Fouché
2012-06-12 13:12 ` Stanislav Meduna
2012-06-12 13:16 ` Nick Garnett
2012-06-12 16:56   ` Bernard Fouché
2012-06-13 10:10     ` Nick Garnett
2012-06-13 16:37       ` Bernard Fouché
2012-06-14 15:33         ` Bernard Fouché
     [not found] ` <>
2012-06-18 14:34   ` Closing devices Frank Pagliughi
2012-06-19 13:36     ` Bernard Fouché
2012-06-20 13:38       ` Frank Pagliughi
2012-06-20 15:20         ` Bernard Fouché
2012-06-21 18:20           ` Frank Pagliughi [this message]
2012-06-22  8:33             ` Bernard Fouché
2012-06-22 14:48               ` Frank Pagliughi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).