Russell King wrote:

>On Thu, Nov 29, 2001 at 08:06:37AM -0800, Balbir Singh wrote:
>
>>Let me make it clearer to you,
>>
>>lets say I call rs_open() on /dev/ttyS0 and if it
>>fails then I should not call rs_close() after a failed
>>rs_open().
>>
>
>You don't call rs_open.  The tty layer does that for you.  The tty layer
>also cleans up on close by calling the driver specific close function.
>
>Yes I agree with you that it might not, but that is a 2.5 kernel issue,
>not a 2.4 "lets do a massive change" issue.  The tty layer is complex
>and messy, and we shouldn't go around randomly changing it in 2.4.
>
>>Lets see what happens with your approach
>>
>>1. I call rs_open(), it fails, ref_count set to 1
>>
>
>Ok, so you're poking around in kernel code calling kernel functions that
>were previously declared static and not visible to anything but the tty
>layer.  That immediately makes your example invalid because you're not
>following the rules that the tty layers lays down for opening tty devices.
>

What I mean by I call rs_open() is that the person who writes the tty layer
should not call close() after open() fails, I cannot directly invoke rs_open()
and rs_close(), I KNOW that.

If I were to define an API like rs_open(), I would expect the person who
uses these API (rs_*) in our case the tty layer, to call rs_close()
only if rs_open() is successfull. I do not want to leave a dependency
that rs_close() SHOULD BE called even if rs_open() failed.

As you say this fix works for 2.4, Since we are into 2.5, I hope
that it will be fixed in a better manner in 2.5. I have some suggestions,
ideas for the serial driver in 2.5, are u willing to discuss them?

Balbir

>
>--
>Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
>             http://www.arm.linux.org.uk/personal/aboutme.html
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>