Date: Mon, 9 Aug 2010 14:47:41 +0200
From: Rodolfo Giometti <giometti@enneenne.com>
To: Alexander Gordeev <lasaine@lvk.cs.msu.su>
Cc: linux-kernel@vger.kernel.org, "Nikita V. Youshchenko" <yoush@cs.msu.su>,
        linuxpps@ml.enneenne.com, john stultz <johnstul@us.ibm.com>,
        Andrew Morton <akpm@linux-foundation.org>, Tejun Heo <tj@kernel.org>,
        Joonwoo Park <joonwpark81@gmail.com>
Message-ID: <20100809124741.GC20272@gundam.enneenne.com>
Mail-Followup-To: Alexander Gordeev <lasaine@lvk.cs.msu.su>,
	linux-kernel@vger.kernel.org,
	"Nikita V. Youshchenko" <yoush@cs.msu.su>, linuxpps@ml.enneenne.com,
	john stultz <johnstul@us.ibm.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Tejun Heo <tj@kernel.org>, Joonwoo Park <joonwpark81@gmail.com>
References: <cover.1280952801.git.lasaine@lvk.cs.msu.su> <244e91439eeb1c835b6fa82999fcd65a8a282183.1280952801.git.lasaine@lvk.cs.msu.su> <20100805093236.GI26615@gundam.enneenne.com> <20100805154231.52555130@desktopvm.lvknet> <20100805123147.GA19407@gundam.enneenne.com> <20100809115343.122c4f2c@desktopvm.lvknet>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20100809115343.122c4f2c@desktopvm.lvknet>
Organization: GNU/Linux Device Drivers, Embedded Systems and Courses
User-Agent: Mutt/1.5.18 (2008-05-17)
Subject: Re: [PATCHv3 05/16] pps: access pps device by direct pointer
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2667
Lines: 65

On Mon, Aug 09, 2010 at 11:53:43AM +0400, Alexander Gordeev wrote:
> 
> Hmm, yes, I see...
> But this is custom problem of only one client. I think it should be
> fixed in place instead of trying to fix it in the subsystem.

I agree with you but I had no luck in doing it in the past... :'(

Maybe you can ask some help to the serial port maintainers or you can
try in pushing the PPS_IRQ_EVENTS solution (see my repository) into
main tree, in fact that solution could resolve two problems at once:

* this one, since we simply read PPS data into an array in RAM, and
* the weak PPS resolution in recording PPS timestamps into normal IRQ
* handlers.

However, the big issue on this solution is about the call of
gettimeofday() for each IRQs into the system (see old mails into this
list about this topic) which slows down the machine's performance.

A workaround (as suggested by Alan Cox if I well remember) could be
adding a flag for each IRQs in order to know if the timestamp must be
recorded or not (testing a flag is not a bit issue for the machine's
performance).

> Are you 100% sure dcd_change can be called before open or after close?
> Then I'll try to deal with this.

Before the open there are no problems since the line discipline is
off, the problem is during the close.

> > > affects performance. So we have to choose what is the priority:
> > > security or performance. My guru told me I shouldn't bother too much
> > > about broken kernel-space code which my code interacts with. If it's
> > > broken it should be fixed. Some assertions enabled by DEBUG define are
> > > enough. For me it makes sense but I don't know what should I check here?
> > 
> > I'm sorry but I disagree with you. Kernel code can't allow userland
> > programs to corrupt it!
> > 
> > We are not discussing about security or performance but about
> > reliability.
> 
> Sure, now I see the problem (in the pps-ldisc).

Yes, the problem is there (and globally in all drivers whose not
directly take care off PPS issues). Unluckely the pps-ldisc is the
most currently used by PPS users...

Ciao,

Rodolfo

-- 

GNU/Linux Solutions                  e-mail: giometti@enneenne.com
Linux Device Driver                          giometti@linux.it
Embedded Systems                     phone:  +39 349 2432127
UNIX programming                     skype:  rodolfo.giometti
Freelance ICT Italia - Consulente ICT Italia - www.consulenti-ict.it
--
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/