RE: Kernel thread in a driver: Unable to wake up thread if I quit the dev file and reopen it.
Hi all, I found finally which CONFIG is involved in my problem. It was CONFIG_ASH_JOB_CONTROL which need to be set. Now my kernel driver can be add and removed and when I quit my app I can relaunch it. My kernel thread is correctly awaken. But I don't know why... I don't understand why this CONFIG is involved in this use case. IF someone knows why, I would be grateful to be informed ;) Cheers. Steph -Original Message- From: Denys Vlasenko [mailto:[EMAIL PROTECTED] Sent: Thursday, September 13, 2007 8:09 PM To: busybox@busybox.net Cc: Stephane Cerveau Subject: Re: Kernel thread in a driver: Unable to wake up thread if I quit the dev file and reopen it. On Thursday 13 September 2007 17:28, Stephane Cerveau wrote: > Hi, > > I'm using busybox 1.1.0 and encounter a problem with a kernel thread > in a char driver. > I have a char driver using a kernel thread awaken(it reads data in a > registry) when it receive an interrupt signal. > When I insert the driver (insmod) and read data in the dev file > (/dev/toto:name of my device), it's working well. > But when i close the dev (quit my app) and relaunch my app. My driver > still receives interrupt but the kernel thread cant be awaken. > > The reason I ask this question in busybox mailing list is that it > seems to depend on busybox config. Indeed I have another busybox > binary > (1.1.3) where all is working fine. So I tried to update my busybox > 1.1.0 to 1.1.3 keeping my old config(I have to keep it) and its also > not working. > So I would like to know if anyone know a config item in busybox which > can interfer with kernel thread or anything close to my problem. > Any answer is welcome :p Can you provide e.g. a strace of old and new programs, with new program exhibitions a problem? (use -tt option to strace too). -- vda ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
Re: kexec in Busybox
On Wednesday 15 August 2007, Andy Kennedy wrote: > Is there plans to add (or has it been added) kexec in busybox? there are no plans ... new applets generally get added as people want i bet things would happen faster if you posted a patch -mike signature.asc Description: This is a digitally signed message part. ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
Re: Busybox utils to set u-boot environment?
On Friday 10 August 2007, Marc Leeman wrote: > > no, nor will there probably ever be due to the nature of u-boot ... every > > single board can store its environment in different types of flash in > > different sectors at different offsets in different magical ways ... > > there is no common infrastructure to query such information from > > kernel/user space > > > > you should setup your mtd maps to create a separate partition for your > > u-boot env sector and then use the mtd-utils package to read/write it > > from userspace > > I do not fully agree with you: U-Boot already contains a firmware > version (fw_setenv and fw_printenv) of the U-Boot setenv and the > printenv commands. thanks, was not aware of those little apps however, the devil is in the details ... there is no requirement the env be stored in flash at all which means mtd access is not guaranteed -mike signature.asc Description: This is a digitally signed message part. ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
Re: telnetd doesn't provide REMOTEHOST environment variable?
On Wednesday 22 August 2007, [EMAIL PROTECTED] wrote: > My application wants/needs to know the address of the host that's > connected via telnet, but the REMOTEHOST variable doesn't seem to be > provided. what's wrong with REMOTE_ADDR ? -mike signature.asc Description: This is a digitally signed message part. ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
Re: [rfc] sed option `-i' (edit in place)
On Monday 27 August 2007, Johan Adolfsson wrote: > Wouldn't we get reduced wearing and possibly a general speed up as well, > if we made sure sed was buffering stuff more and avoiding small writes > to the filesystem? > Then there shouldn't be much difference in flash wearing compared to a > copy. any decent flash filesystem will handle these details at the kernel level -mike signature.asc Description: This is a digitally signed message part. ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
Re: [rfc] sed option `-i' (edit in place)
On Sunday 26 August 2007, Cristian Ionescu-Idbohrn wrote: > On Sun, 26 Aug 2007, Denys Vlasenko wrote: > > I think that sed creates new file, fills it and and then renames > > new file into old file so fast that first metadata update doesn't > > even have time to hit the disk storage before it's all done. > > I believe that may be the case with most fs, but not jffs2. But don't > take my word for it. jffs2 appends changes to erased pages, so there shouldnt be any overhead of erasing the sectors the old file was taking ... it'll get garbage collected like all other old files at some point overall though, i'd have to agree with Denys about making a dynamic flag bloating things ... but it does suck about having to do this on flash filesystems perhaps you should post a patch that makes a config option that forces all inline seds to take a predefined path to use ... [*] Use a system path for temp files /tmp/ -mike signature.asc Description: This is a digitally signed message part. ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
Re: issue regarding ESC in vi
On Friday 07 September 2007, Paul Fox wrote: > > On Thursday 06 September 2007 22:49, Tapojoy chatterjee wrote: > > > hi > > > whenever we press ESC in vi there is flashing of the terminal..is > > > there a way around it > > > > I'm not using vi myself, but looking at vi.c, there is some obscure way > > to toggle bell/flash notification. > > > > grep for "bell" in vi.c > : > :set noflash i dont see this option in POSIX anywhere and default vi nowadays doesnt do that by default ... perhaps we should invert the defaults ? i dont see value in something that annoys most people and is pretty worthless ... -mike signature.asc Description: This is a digitally signed message part. ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
Re: moving /bin/ip to /sbin/ip?
On Tuesday 11 September 2007, Denys Vlasenko wrote: > On Tuesday 11 September 2007 05:01, Paul Fox wrote: > > > On Mon, Sep 10, 2007 at 10:40:11PM +0200, Natanael Copa wrote: > > > > It would be a lot easier for me to have the ip application in the > > > > same place as the original iproute2. In fact it makes things alot > > > > more easy to have the busybox applications in the same place as the > > > > original apps. (not first time i meet this kind of problems) > > > > > > $PATH? > > > > no, his problem is that other apps refer to ip via its full path. > > $PATH isn't always the answer. > > Which is kind of negates the reason why we have PATH in the first place. > > "Other apps" should be fixed to not use full paths. generally yes ... however, i dont know of any distro who puts `ip` in /bin and considering its purpose in life (configuring the interfaces), putting it in /sbin makes sense to me -mike signature.asc Description: This is a digitally signed message part. ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
Re: Unknown server error
On Wednesday 12 September 2007, nita lohia wrote: i dont think you quite get the purpose of the busybox list ... this is not a general forum for answering general linux questions ... please visit a general linux forum like linuxquestions.org -mike signature.asc Description: This is a digitally signed message part. ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
Re: busybox 1.6.1 miscutils/taskset problem with glibc, wrong number of params
On Thursday 13 September 2007, Paul Barrette wrote: > This toolchain was made by tool call ltib from bitshrine.org. Changing > the toolchain mid project is not an option for us. Probably before the > next I will. then you'll have to change the code locally ... this isnt a bug in busybox -mike signature.asc Description: This is a digitally signed message part. ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
