persistent data

C
Jiri Baum wrote:

> > I think this communications should be through the shared memory like everything else.
>
> Yes, everything should be through the shared memory.
>
> But note that semaphores have to be separate. I was putting them in the
> We'll Do That Later category, though (besides, the kernel provides them).

Yes, but are they visible/usable from kernel code?
cww

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Thu, 27 Jan 2000, Curt Wuollet wrote:

> > Yes, everything should be through the shared memory.
> >
> > But note that semaphores have to be separate. I was putting them in the
> > We'll Do That Later category, though (besides, the kernel provides them).
>
> Yes, but are they visible/usable from kernel code?
> cww

As in useable by RT stuff????
Otherwise why do they need to be?


Dave West E-Mail: [email protected]
Semiras Projects Ltd. PGP public key available on request.


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Thu, 27 Jan 2000 [email protected] wrote:

> >> Hmm, a sorted list of timers sorted by when they would expire... didn't
> >> think of that one. Could be quite fast.
> >
> >You don't even need a real sort. A priority queue (also known as a "heap",
> >as in "heap-sort") is enough and has O(log n) insertion / deletion time
> >with constant time to access first element.
>
> Was probably like what I was thinking about :)
>
> >> >To do this you need a free running clock such as the jiffies counter and
> >> >always compare against that. Note I have not mentioned wall-time as I
> >> >think this free running timer should start when the PLC logic is started
> >> >and have absolutely no relation to wall-time.
> >
> >OK, but be careful with that - make sure you know how long the jiffies
> >counter will last and what happens when it rolls over.
>
> That's easy enough if you make all caclulations using the same
> register size as the original variables and always uses time
> differences, and expect it to roll over.
>
> instead of: (NOTE! this code is WRONG)
> if (now>start+time)
> ...
>
> you write:
> if (now-start>time)
> ...
>
> Think about what will happen when start+time is a number
> higher than can be represented by the selected variable.
> btw. some kind of unsigned integers (any size) is probably the
> best to use for these ku_nd of caclulations.
>
> My suggestion is (if this kind of code is to be implemented)
> a fairly low amount of bits is used. Like that it will wrap
> within hours at least. This will make bugs appear and be fixed
> instead of hiding them by the fact that noone wants to debug that long.
>
> Like using 32 bits and use usec resolution (sligtly more than
> 1 hour) actual resolution may be lower depending on the system.

No use, You cannot time for more than 2 hours!!!

> or if msec resolution is to be used, not use more than 16 bits
> (will wrap after a little bit more than 1 minute)
>

See above.

Bsically if the counter + offset value is double the counters scale then you timer fails entirely. It needs to be a BIG number. For debugging our
code you can use a shorter type and simply increase it to a bigger one once the algorythm is sorted. This code should never need to be re vamped and as such only need written once and will never break.

Dave West E-Mail: [email protected]
Semiras Projects Ltd. PGP public key available on request.


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
C
Dave West wrote:

> > > But note that semaphores have to be separate. I was putting them in the
> > > We'll Do That Later category, though (besides, the kernel provides them).
> >
> > Yes, but are they visible/usable from kernel code?
> > cww
>
> As in useable by RT stuff????
> Otherwise why do they need to be?

RT stuff and board drivers that need interrupts.
cww

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Thu, Jan 27, 2000 at 07:48:56PM +0000, Curt Wuollet wrote:
> Jiri Baum wrote:

> > But note that semaphores have to be separate. I was putting them in the
> > We'll Do That Later category, though (besides, the kernel provides them).

> Yes, but are they visible/usable from kernel code?

I don't know, but frankly I don't really care.

Either they can be, or the RT group will give us a wrapper function we can call instead of semop(2). Semaphores are a sufficiently basic requirement that we can assume they will exist everywhere.


Jiri
--
Jiri Baum <[email protected]>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Thu, Jan 27, 2000 at 12:49:17PM +0000, Dave West wrote:
> If I understand this correctly you are saying that the internal clock
> will add 86400 seconds to itself at 23:59:59 on 28/2/2100 because the
> library functions are broken!

> BTW which man page did you get this from?

time(2) from Linux 2.0.30, dated 9 September 1997.

It quotes this as coming from POSIX.1, particularly Annex B 2.2.2.


Maybe the intention was that by the time 2100 rolls around POSIX.1 will have been supplanted by something sane in this area.

Jiri
--
Jiri Baum <[email protected]>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
C
Hi Jiri

We need to care. You can't code for something that isn't there. I think we need to find out. If we don't have them we can simulate them or use
something else for synchronization. I'll do some looking, but we ahould have a plan B. I'd like something in the map. Drivers will need to sync
and at least some will have to run in kernel space.

Regards,

Curt




Jiri Baum wrote:
>
> On Thu, Jan 27, 2000 at 07:48:56PM +0000, Curt Wuollet wrote:
> > Jiri Baum wrote:
>
> > > But note that semaphores have to be separate. I was putting them in the
> > > We'll Do That Later category, though (besides, the kernel provides them).
>
> > Yes, but are they visible/usable from kernel code?
>
> I don't know, but frankly I don't really care.
>
> Either they can be, or the RT group will give us a wrapper function we can
> call instead of semop(2). Semaphores are a sufficiently basic requirement
> that we can assume they will exist everywhere.
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Curt Wuollet:
> We need to care. You can't code for something that isn't there. I think
> we need to find out. If we don't have them we can simulate them or use
> something else for synchronization.

Semaphores are *basic*. Every environment will provide them, either itself or in the form of sample code.

You can code to a generic semaphore - it has a signal function and a wait function, and ensures that at any time the signal function had completed at least as many times as the wait function.

> I'll do some looking, but we ahould have a plan B. I'd like something in
> the map. Drivers will need to sync and at least some will have to run in
> kernel space.

I don't think a plan B *can* exist. Either you have sufficient primitives to construct a semaphore, or you can't do multiprocessing safely. I don't think there's any third possibility.

That's what I meant by "don't care". They *are* important; but I'm certain that they'll be provided, and the exact form of the function call is unimportant.

> > Semaphores are a sufficiently basic requirement that we can assume they
> > will exist everywhere.


Jiri
--
Jiri Baum <[email protected]>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
C
Hi Jiri,

A simple grep through the driver code in /usr/src/linux says that semaphores of some sort are available. My point, in professing my ignorance and asking, is that it's time to move from totally blue sky to how we implement in Linux. I didn't mean to use you personally as an example, whenever possible I'll be the dumb guy and ask questions. We have some firm constraints. Quite a bit of the stuff I see ignores those constraints. Some of what I see ignores *nix
practice and philosophy completely and invents things that are already available as OS services. I think from your response that you see my point
that "I don't know, I'll find out" is more useful than "I don't care". Please forgive my intrusion as well intended.

For some of this first crucial code the project has a real problem. We need people who have experience in writing to Linux at the kernel level. I have precious little of that experience, I've hacked together a driver or two that work, but I am worried that the foundation be efficient, solid, and takes the best possible advantage of the OS. These are goals that we all
can agree on as they make things easier and better all around. As we go up towards the application level, we have lots of capable. if
opinionated ;^), talent. I need help to address this concern. I have had few serious inquiries about the developers list. I have asked some people and got some favorable responses. We really need to sift through the list and identify, without ego or prejudice, the individuals that can "walk the walk". I, for example, have a good grasp on what I don't know and and am hoping we have better talent than myself available. I have even posted on a few other lists to see if we can attract a serious kernel hacker on at least an advisory level. I ask all in the list to help find the best people for the Linux specific layer.

All comments and suggestions welcome.

Curt Wuollet.
Wide Open Technologies.


Jiri Baum wrote:
>
> Curt Wuollet:
> > We need to care. You can't code for something that isn't there. I think
> > we need to find out. If we don't have them we can simulate them or use
> > something else for synchronization.
>
> Semaphores are *basic*. Every environment will provide them, either itself
> or in the form of sample code.
>
> You can code to a generic semaphore - it has a signal function and a wait
> function, and ensures that at any time the signal function had completed at
> least as many times as the wait function.
>
> > I'll do some looking, but we ahould have a plan B. I'd like something in
> > the map. Drivers will need to sync and at least some will have to run in
> > kernel space.
>
> I don't think a plan B *can* exist. Either you have sufficient primitives
> to construct a semaphore, or you can't do multiprocessing safely. I don't
> think there's any third possibility.
>
> That's what I meant by "don't care". They *are* important; but I'm certain
> that they'll be provided, and the exact form of the function call is unimportant. <clip>

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Curt Wuollet :
> A simple grep through the driver code in /usr/src/linux says that
> semaphores of some sort are available.
...
> I think from your response that you see my point that "I don't know, I'll
> find out" is more useful than "I don't care". Please forgive my
> intrusion as well intended.

I think I should be the one apologising; "I don't care" really isn't a very good way of putting what I was trying to express.

It was the details I didn't care about, and in the overall view I was certain that semaphores are available; it can't work otherwise. So I
figured I'd use semop(2) until there's a reason to switch to something else, at which point it's a simple matter of doing a search-and-fix.

Since I don't have any experience with RT Linux or kernel drivers, I assumed that it'd be someone else who would find out that something special
has to be done for semaphores, and write appropriate wrappers.

> I have had few serious inquiries about the developers list. I have asked
> some people and got some favorable responses. We really need to sift
> through the list and identify, without ego or prejudice, the individuals
> that can "walk the walk".

I don't think there's a need at this stage, and we'd probably lose more in a list-split than we'd gain - especially now that one of the most prolific posters has left (because of standards *compliance*).


Jiri
--
Jiri Baum <[email protected]>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
C
Jiri Baum wrote:
>
> Curt Wuollet :
> > A simple grep through the driver code in /usr/src/linux says that
> > semaphores of some sort are available.
> ...
> > I think from your response that you see my point that "I don't know, I'll
> > find out" is more useful than "I don't care". Please forgive my
> > intrusion as well intended.
>
> I think I should be the one apologising; "I don't care" really isn't a very
> good way of putting what I was trying to express.
>
> It was the details I didn't care about, and in the overall view I was
> certain that semaphores are available; it can't work otherwise. So I
> figured I'd use semop(2) until there's a reason to switch to something
> else, at which point it's a simple matter of doing a search-and-fix.
>
> Since I don't have any experience with RT Linux or kernel drivers, I
> assumed that it'd be someone else who would find out that something special
> has to be done for semaphores, and write appropriate wrappers.

Exactly, I'm concerned about who that someone else is.
>
> > I have had few serious inquiries about the developers list. I have asked
> > some people and got some favorable responses. We really need to sift
> > through the list and identify, without ego or prejudice, the individuals
> > that can "walk the walk".
>
> I don't think there's a need at this stage, and we'd probably lose more in
> a list-split than we'd gain - especially now that one of the most prolific
> posters has left (because of standards *compliance*).

While we don't necessarily need a list split due to reduced volume, we do need to get a handle on where our Linux expertise is. and get that discussion focused on implementation. I finally got a chance to study the stuff in the cvs archive. and was well impressed. Phil, Simon, myself and the others deeply interested in
low level stuff should talk as there are some differences. I am trying to write to the map based on the membuf stuff and will need to dig some more.

I hope we haven't lost anyone permanently, It's just that fight^h^h^h^hdiscussion can take place later, when those issues are being addressed.
cww

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
S

Simon Martin

Hi Curt,

With respect your mail about expertise, I have about 15 years experience in C in multitasking/multiprocessing/real-time(servo) environments. I have been involved in *NIX base systems for about 2/3 years now. I have used pthreads and forks, process interlocks (using pmutex, lock files, etc.).

I have no experience with the real-time linux patches.

By the way I had a wonderful holiday and am back on-line again. Next week I will be in the UK and will have more time available for this project (at
least 2 hours a day).

Read you soon.

Debian GNU User
Simon Martin
Project Manager
Isys
mailto: [email protected]


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Simon Martin,

> I come to you cap in hand. I have just come back on-line after a rather
> interesting return to Chile. Do you still want/need my source code?

Oops, yes I'm still waiting for it... (not that Real Life wouldn't be keeping me busy, but still).


Jiri
--
Jiri Baum <[email protected]>
Windows is not popular. Windows is *widespread*. Linux is popular.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Top