Menu
▾
▴
lcd4linux-users
|
From: Luis.F.Correia <Lui...@se...> - 2003-08-06 07:35:53
|
> [...] > > dvb.c: In function `DVB': > > dvb.c:57: warning: implicit declaration of function `error' > > This has been fixed in CVS. But it's only a warning :-) No problem. I do tend to ignore such errors > > lcd4linux.o: In function `main': > > /bering/lcd4linux-0.9.9/lcd4linux.c:308: undefined > reference to `rpl_malloc' > > collect2: ld returned 1 exit status > > Hmm... I looked things up on the internet, and found this a little > glitch or bug in the autoconf area. > > Could you please try to comment out the "AC_FUNC_MALLOC" line from > configure.in? > I did commented out the #define malloc rpl_malloc in config.h, and all went well Now I do have another issue, since our firewall distro came out, Bering-uClibc, i have been using lcdproc as a primary display. But now that we have secured our firewall with the grsecurity patches, 'previledge io' (ioperm()) does not work anymore... So, logically i switched to test LCD4linux, using the parport device. Our firewall's filesystem is in RAM and is rebuilt on every boot. Meaning that all /dev entries must be created also. I need some help here, to use parport.o and to have the device correctly created, what do I need to do? Thanks! |
|
From: Luis.F.Correia <Lui...@se...> - 2003-08-06 08:15:40
|
Michael, > > Hi Luis, > > >>Hmm... I looked things up on the internet, and found this a little > >>glitch or bug in the autoconf area. > >> > >>Could you please try to comment out the "AC_FUNC_MALLOC" line from > >>configure.in? > > > > I did commented out the #define malloc rpl_malloc in config.h, and > > all went well > > Fine. But I'd really like you to test my suggestion, because config.h > will be newly created with a 'configure'-run. I'll do so later on. My devel sys is stabler at home ;) > > > Our firewall's filesystem is in RAM and is rebuilt on every boot. > > Meaning that all /dev entries must be created also. > > > > I need some help here, to use parport.o and to have the device > > correctly created, what do I need to do? > > Are you using devfs? THen all /dev entries will be created > automagically. > No, we are not (yet) using devfs... > Without devfs, you'll have to create the device manually. I'm > not shure > whats the correct name, but I'd suggest: > > c 99 0 /dev/parport0 > c 99 1 /dev/parport1 > c 99 2 /dev/parport2 > That is done with mknod, right? And when the parport module is loaded (which is not built in the kernel), all will work? > Of course you have to change the "Port" entry in the lcd4linux.conf. I thought so... |
|
From: Michael R. <re...@eu...> - 2003-08-06 08:41:50
|
Hi, >>c 99 0 /dev/parport0 > > That is done with mknod, right? Yes. > And when the parport module is loaded (which is not built in the kernel), > all will work? I think so, yes. If not, let me know. good luck! bye, michael -- netWorks Vox: +43 316 698260 Michael Reinelt Fax: +43 316 692343 Geisslergasse 4 GSM: +43 676 3079941 A-8045 Graz, Austria e-mail: re...@eu... |
|
From: Luis.F.Correia <Lui...@se...> - 2003-08-06 12:50:22
|
Michael, can you provide me with the correct modules relevant to make lcd4linux work using ppdev? I'm somewhat confused, sorry. > -----Original Message----- > From: Michael Reinelt [mailto:re...@eu...] > Sent: Wednesday, August 06, 2003 9:41 AM > To: Luis.F.Correia > Cc: lcd...@li... > Subject: Re: [lcd4linux] rpl_malloc? > > > Hi, > > >>c 99 0 /dev/parport0 > > > > That is done with mknod, right? > > Yes. > > > And when the parport module is loaded (which is not built > in the kernel), > > all will work? > > I think so, yes. If not, let me know. > > good luck! > > bye, michael > > -- > netWorks Vox: +43 316 698260 > Michael Reinelt Fax: +43 316 692343 > Geisslergasse 4 GSM: +43 676 3079941 > A-8045 Graz, Austria e-mail: re...@eu... > |
|
From: Luis.F.Correia <Lui...@se...> - 2003-08-06 20:41:45
|
Michael, it does work ;) it needs parport_pc + parport + ppdev. I have some complains... in our system we do not have /prog/kcore, so lots of info do not appear. From the docs and the token list, i cannot find the equivalent of 'uptime'. Are there any plans to add it soon? One other thing, we use the Debian start-stop-daemon script to start, stop and restart our daemons. The daemon must know about the 'pid' file. can you add support? I'm not quite sure now of the exact needs, but i can tell you tomorrow. Thanks for this great software, it is possible that you will see it soon as one of our add-on packages. Take care! > -----Original Message----- > From: Michael Reinelt [mailto:re...@eu...] > Sent: Wednesday, August 06, 2003 9:41 AM > To: Luis.F.Correia > Cc: lcd...@li... > Subject: Re: [lcd4linux] rpl_malloc? > > > Hi, > > >>c 99 0 /dev/parport0 > > > > That is done with mknod, right? > > Yes. > > > And when the parport module is loaded (which is not built > in the kernel), > > all will work? > > I think so, yes. If not, let me know. > > good luck! > > bye, michael > > -- > netWorks Vox: +43 316 698260 > Michael Reinelt Fax: +43 316 692343 > Geisslergasse 4 GSM: +43 676 3079941 > A-8045 Graz, Austria e-mail: re...@eu... > |
|
From: Michael R. <re...@eu...> - 2003-08-07 15:23:40
|
Hi Luis, > it does work ;) Fine! > it needs parport_pc + parport + ppdev. Thats what I would have told you. > in our system we do not have /prog/kcore, so lots of info do not appear. The only client that uses /proc/kcore is "Ram" (forgot about the token=20 now), it uses "sizeof(/proc/kcore)" because /proc/meminfo gives wrong=20 results here. Or do you mean you don't have /proc at all? That would be bad... >>From the docs and the token list, i cannot find the equivalent of 'upti= me'. > Are there any plans to add it soon? No. This is a good example for a plugin. have a look at the "%x" tokens... > One other thing, we use the Debian start-stop-daemon script to start, s= top > and restart our daemons. > The daemon must know about the 'pid' file. can you add support? I will do so. But not really soon, because I've run into a problem: my=20 notebook was stolen during a flight from d=FCsseldorf to graz. Shit! > I'm not quite sure now of the exact needs, but i can tell you tomorrow. Fine, tell me tomorrow :-) > Thanks for this great software, it is possible that you will see it soo= n as > one of our add-on packages. This would be great! btw, who is "we"? what's your "main package"? anyway, I will place a linkt to whatever-it-is on the lcd4linux homepage = :-) bye, michael --=20 netWorks Vox: +43 316 698260 Michael Reinelt Fax: +43 316 692343 Geisslergasse 4 GSM: +43 676 3079941 A-8045 Graz, Austria e-mail: re...@eu... |
|
From: Luis.F.Correia <Lui...@se...> - 2003-08-07 15:30:36
|
Quick reply ;) > -----Original Message----- > From: Michael Reinelt [mailto:re...@eu...]=20 > Sent: Thursday, August 07, 2003 4:24 PM > To: Luis.F.Correia > Cc: lcd...@li... > Subject: Re: [lcd4linux] rpl_malloc? >=20 >=20 > Hi Luis, >=20 > > it does work ;) > Fine! >=20 > > it needs parport_pc + parport + ppdev. > Thats what I would have told you. >=20 I know that now, i didn't RTFM enough ;) > > in our system we do not have /prog/kcore, so lots of info=20 > do not appear. > The only client that uses /proc/kcore is "Ram" (forgot about=20 > the token=20 > now), it uses "sizeof(/proc/kcore)" because /proc/meminfo gives wrong = > results here. >=20 > Or do you mean you don't have /proc at all? That would be bad... >=20 We do have /proc, but one of our security fixes, grsecurity, disables access to /proc/kcore. We will find a way to display the correct amount of system memory. > >>From the docs and the token list, i cannot find the=20 > equivalent of 'uptime'. > > Are there any plans to add it soon? > No. This is a good example for a plugin. have a look at the=20 > "%x" tokens... I will. >=20 > > One other thing, we use the Debian start-stop-daemon script=20 > to start, stop > > and restart our daemons. > > The daemon must know about the 'pid' file. can you add support? > I will do so. But not really soon, because I've run into a=20 > problem: my=20 > notebook was stolen during a flight from d=FCsseldorf to graz. Shit! Very bad indeed, I hope you can sue the travel agency for that... > > I'm not quite sure now of the exact needs, but i can tell=20 > you tomorrow. > Fine, tell me tomorrow :-) >=20 > > Thanks for this great software, it is possible that you=20 > will see it soon as > > one of our add-on packages. > This would be great! >=20 > btw, who is "we"? what's your "main package"? We, the Bering uClibc team. http://leaf.sourceforge.net/mod.php?mod=3Duserpage&menu=3D910&page_id=3D= 36 >=20 > anyway, I will place a linkt to whatever-it-is on the=20 > lcd4linux homepage :-) Please, put the link only when we have a finished package. :) I'm testing it now. Some changes must be made until we consider it production package. The most important is the start-stop thing... Have fun! |
|
From: Michael R. <re...@eu...> - 2003-08-07 16:33:12
|
Hi,
Luis.F.Correia schrieb:
> Quick reply ;)
By accident. Sitting in the office without my notebook doesn't make too=20
much sense :-(
>>>in our system we do not have /prog/kcore, so lots of info=20
>>do not appear.
>>The only client that uses /proc/kcore is "Ram" (forgot about=20
>>the token=20
>>now), it uses "sizeof(/proc/kcore)" because /proc/meminfo gives wrong=20
>>results here.
> We do have /proc, but one of our security fixes, grsecurity, disables
> access to /proc/kcore.
Hmm... I do not "access" it. I just call 'stat("/proc/kcore", &buf)'. I=20
don't understand why this is disabled, I don't see any security reasons=20
here.
> We will find a way to display the correct amount of system memory.
Well, I've to change this thing anyway, because I recently noticed that=20
with "highmem" (or whatever this stuff is called) gives wrong results=20
with the sizeof(kcore) approach.
Anybody has got a hint how to detect the "real" amount of memory built=20
into a PC?
>>>>From the docs and the token list, i cannot find the=20
>>equivalent of 'uptime'.
>>No. This is a good example for a plugin. have a look at the=20
>>"%x" tokens...
There's another thread "Text overlay problem", looks like this guy=20
already has written (or stolen :-) such a plugin.
>>my
>>notebook was stolen during a flight from d=FCsseldorf to graz. Shit!
> Very bad indeed, I hope you can sue the travel agency for that...
No, I can't. Nobody can. It's explicitly stated in their=20
"Bef=F6rderungsbedingungen" (what's the english word?) that electronic=20
devices such as computers are not assured. And even if they would be,=20
not based on their value, but only on weight! Strange...
>>>The daemon must know about the 'pid' file. can you add support?
> Some changes must be made until we consider it production package.
> The most important is the start-stop thing...
Ok, I will implement this stuff really soon (at least I'll try to).
Anybody with hints where one could steal^Hlook up good code for pid file=20
handling?
What should happen if there are two instances of lcd4linux running? Two=20
pid files?
bye, Michael
--=20
netWorks Vox: +43 316 698260
Michael Reinelt Fax: +43 316 692343
Geisslergasse 4 GSM: +43 676 3079941
A-8045 Graz, Austria e-mail: re...@eu...
|
|
From: Luis.F.Correia <Lui...@se...> - 2003-08-07 16:39:22
|
> >>>in our system we do not have /prog/kcore, so lots of info=20
> >>do not appear.
> >>The only client that uses /proc/kcore is "Ram" (forgot about=20
> >>the token=20
> >>now), it uses "sizeof(/proc/kcore)" because /proc/meminfo=20
> gives wrong=20
> >>results here.
> > We do have /proc, but one of our security fixes,=20
> grsecurity, disables
> > access to /proc/kcore.
>=20
> Hmm... I do not "access" it. I just call 'stat("/proc/kcore",=20
> &buf)'. I=20
> don't understand why this is disabled, I don't see any=20
> security reasons=20
> here.
If you have /proc/kcore you can open it and read/write the memory
positions...
>=20
> > We will find a way to display the correct amount of system memory.
>=20
> Well, I've to change this thing anyway, because I recently=20
> noticed that=20
> with "highmem" (or whatever this stuff is called) gives wrong results =
> with the sizeof(kcore) approach.
>=20
> Anybody has got a hint how to detect the "real" amount of=20
> memory built=20
> into a PC?
>=20
> >>>>From the docs and the token list, i cannot find the=20
> >>equivalent of 'uptime'.
> >>No. This is a good example for a plugin. have a look at the=20
> >>"%x" tokens...
>=20
> There's another thread "Text overlay problem", looks like this guy=20
> already has written (or stolen :-) such a plugin.
>=20
>=20
> >>my
> >>notebook was stolen during a flight from d=FCsseldorf to graz. =
Shit!
> > Very bad indeed, I hope you can sue the travel agency for that...
> No, I can't. Nobody can. It's explicitly stated in their=20
> "Bef=F6rderungsbedingungen" (what's the english word?) that =
electronic=20
"Terms of use"?
> devices such as computers are not assured. And even if they would be, =
> not based on their value, but only on weight! Strange...
>=20
> >>>The daemon must know about the 'pid' file. can you add support?
> > Some changes must be made until we consider it production package.
> > The most important is the start-stop thing...
>=20
> Ok, I will implement this stuff really soon (at least I'll try to).
>=20
> Anybody with hints where one could steal^Hlook up good code=20
> for pid file=20
> handling?
No. well at least no now... i'll keep you posted.
>=20
> What should happen if there are two instances of lcd4linux=20
> running? Two=20
> pid files?
This should not happen. At least on a router.
|
|
From: Michael R. <re...@eu...> - 2003-08-08 08:09:34
|
Hi Luis,
>>>We do have /proc, but one of our security fixes,
>>grsecurity, disables
>>>access to /proc/kcore.
>>
>>Hmm... I do not "access" it. I just call 'stat("/proc/kcore",
>>&buf)'. I
>>don't understand why this is disabled, I don't see any
>>security reasons
>>here.
>
> If you have /proc/kcore you can open it and read/write the memory
> positions...
Ok, I understand. grsecurity does not disbale access, but diables
/proc/kcore as a whole?
>>>>>The daemon must know about the 'pid' file. can you add support?
Done, but in CVS only. Could you please test? As soon as I've got your
Ok, I will release 0.9.10
bye, Michael
--
netWorks Vox: +43 316 698260
Michael Reinelt Fax: +43 316 692343
Geisslergasse 4 GSM: +43 676 3079941
A-8045 Graz, Austria e-mail: re...@eu...
|
|
From: Michael R. <re...@eu...> - 2003-08-06 07:57:45
|
Hi Luis, >>Hmm... I looked things up on the internet, and found this a little >>glitch or bug in the autoconf area. >> >>Could you please try to comment out the "AC_FUNC_MALLOC" line from >>configure.in? > > I did commented out the #define malloc rpl_malloc in config.h, and > all went well Fine. But I'd really like you to test my suggestion, because config.h will be newly created with a 'configure'-run. > Our firewall's filesystem is in RAM and is rebuilt on every boot. > Meaning that all /dev entries must be created also. > > I need some help here, to use parport.o and to have the device > correctly created, what do I need to do? Are you using devfs? THen all /dev entries will be created automagically. Without devfs, you'll have to create the device manually. I'm not shure whats the correct name, but I'd suggest: c 99 0 /dev/parport0 c 99 1 /dev/parport1 c 99 2 /dev/parport2 Of course you have to change the "Port" entry in the lcd4linux.conf. bye, Michael -- netWorks Vox: +43 316 698260 Michael Reinelt Fax: +43 316 692343 Geisslergasse 4 GSM: +43 676 3079941 A-8045 Graz, Austria e-mail: re...@eu... |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X