BOUNCE rtl@rtlinux.org: Approval required: (fwd)

[Der Herr Hofrat <der.herr@hofr.at>]

>From owner-rtl Mon Jul  9 03:03:07 2001
Received: from gw-nl4.philips.com (gw-nl4.philips.com [212.153.190.6])
	by hq.fsmlabs.com (8.11.2/8.11.2) with ESMTP id f69936T04841
	for <rtl@fsmlabs.com>; Mon, 9 Jul 2001 03:03:06 -0600
Received: from smtpscan-nl2.philips.com (localhost.philips.com [127.0.0.1])
          by gw-nl4.philips.com with ESMTP id KAA11774
          for <rtl@fsmlabs.com>; Mon, 9 Jul 2001 10:56:11 +0200 (MEST)
          (envelope-from Iwo.Mergler@soton.sc.philips.com)
Received: from smtpscan-nl2.philips.com(130.139.36.22) by gw-nl4.philips.com via mwrap (4.0a)
	id xma011772; Mon, 9 Jul 01 10:56:11 +0200
Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) 
	by smtpscan-nl2.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id KAA05218
	for <rtl@fsmlabs.com>; Mon, 9 Jul 2001 10:56:09 +0200 (MET DST)
Received: from kilkenny.soton.sc.philips.com (mailgate.soton.sc.philips.com [130.141.89.1]) 
	by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id KAA17839
	for <rtl@fsmlabs.com>; Mon, 9 Jul 2001 10:56:08 +0200 (MET DST)
Received: from scorpion.soton.sc.philips.com (root@[130.141.7.31])
	by kilkenny.soton.sc.philips.com (8.11.3/8.11.3) with ESMTP id f698FLv15507
	for <rtl@fsmlabs.com>; Mon, 9 Jul 2001 09:15:21 +0100
Received: from soton.sc.philips.com (calders [130.141.7.59])
	by scorpion.soton.sc.philips.com (8.9.3/8.9.3) with ESMTP id JAA12201
	for <rtl@fsmlabs.com>; Mon, 9 Jul 2001 09:56:07 +0100 (BST)
Sender: mergler@soton.sc.philips.com
Message-ID: <3B4971A7.95F01FF1@soton.sc.philips.com>
Date: Mon, 09 Jul 2001 09:56:07 +0100
From: Iwo Mergler <Iwo.Mergler@soton.sc.philips.com>
Reply-To: Iwo.Mergler@soton.sc.philips.com
Organization: Philips Semiconductors
X-Mailer: Mozilla 4.51 [en] (X11; I; HP-UX B.11.00 9000/785)
X-Accept-Language: en
MIME-Version: 1.0
To: rtl@fsmlabs.com
Subject: Re: [rtl] Newbieproblems - stacksize
References: <Pine.LNX.4.21.0107081241090.25079-100000@carlsberg.kampsax.dtu.dk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Nicolai Hanssing wrote:
> 
> First off, Michael thanks for your answers.
> 
> > > By atomic, I mean non-divideble - i.e. You put something of size 30B in
> > > RTFx from userspace, and when the handler get woken theres 30B in the RTFx.
> >
> > Kernel rtf_put and user-space write are atomic in this sense.
> > rtf_get or a user-space read may return with less data than requested
> > if there's not enough data in the FIFO.
> 
> Thats not really my question, I'll try again:
> If a userspace task only writes blocks of 30 bytes to an RTF-fifo, and the
> rtl taks reads blocks of 30 bytes, can the task then return a read with
> less than 30 bytes?
> I.e. are the data from the userspace "committed" to
> the fifo partly ?
> Also of intrest: When is the rtf-handler woken?
> At the end of operations
> on the fifo - bucause that would gice the false effect of an atomic fifo,
> allthough it might not be.
> 

I had a similar problem here. My device can slow down
it's data stream, given early enough warning. What I need is
a way to detect a 'nearly empty' FIFO. I solved it by adding 
this function to rtl_fifo.c :

int rtf_size(unsigned int minor)
{
	return RTF_LEN(minor);
}

Obviously, this is a dirty hack. Is there an official
way to get the fill size of a FIFO?
Or a good reason why not?

Have a nice day.

Iwo

----- End of forwarded message from owner-rtl@fsmlabs.com -----