Re: single, comprehensive kernel data types document?
On Thu, Apr 21, 2016 at 08:51:04AM -0400, Rob Groner wrote: > On Thu, 2016-04-21 at 11:51 +0900, Greg KH wrote: > > On Wed, Apr 20, 2016 at 04:37:07PM -0400, Rob Groner wrote: > > > Sorry if this isn't related, it seemed like it was... > > > > > > I recently discovered one of our drivers isn't written correctly for > > > 64-bit. It uses a uint32_t to hold an address. Whoops. > > > > > > In previous drivers when I've needed to hold an address, I've used an > > > "unsigned long", as (so far as I could tell) that would give me the > > > correct number of bytes whether on 32 or 64-bit systems. > > > > > > Now that I have to fix this driver, I'd rather do whatever the > > > "standard" method is for storing an address value. > > > > > > Looking at code in the kernel and linux/types.h, I see "phys_addr_t and > > > dma_addr_t. Is that what I want to use? What if it's a virtual > > > address? void *? > > > > You want to use '__u64' and cast properly within the kernel to a > > pointer. > > > > hope this helps, > > > > greg k-h > > Thank you Greg. > > I was thinking there was a type that would hold a memory address (like > an allocated DMA buffer address, or a PCI address) that would be the > correct size on a 32-bit or 64-bit system without me having to specify a > size. If I use __u64 to hold a memory address, won't that be the wrong > size on a 32-bit system? It will be bigger than is strictly necessary in that specific case, but is that a problem? Also, please consider the case where a user is running a 32-bit userspace and a 64-bit kernel. Not making datastructures which cross the user/kernel boundaries make use of the largest fixed-width[1] type means that the kernel would have to handle this case differently (in fact, you can find many 'compat' examples in the kernel tree which do just that, because the types were incorrectly used). And, that's just terrible :(. Josh 1: Just wanted to add it's not just about size of these datatypes, either. It's about their alignment. signature.asc Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Kernel gets deadlocked during smp booting
On Wed, Jun 17, 2015 at 12:09:10PM +0530, AYAN KUMAR HALDER wrote: > > Could you post the full backtrace (straight from the kernel log)? > The backtrace has been obtained from a debugger, not from the kernel > log (as the kernel has been deadlocked). The backtrace is as follows:- Unfortunately, this trace shows you what you already know. You mention that SMP is enabled; are you running on a system that supports SMP, or are you relying on SMP_ON_UP to patch things up? If another CPU has been brought up, then its backtrace is likely more interesting to you. Josh pgpRMvUJJN58i.pgp Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: SOC: Zedboard: Driver question
On Thu, Jun 12, 2014 at 04:39:25PM +0300, amit mehta wrote:
> We are working on a school project in which we are trying to develop a
> audio mixer on Zedboard (Development board from Digilent). We have
> developed the IP and have integrated it with the overall hardware
> using Programmable logic. This board has ARM core. We have a Digilent
> pre-configured Linux source which we cross-compiled for ARM board,
> device tree blob and bootloader for Zync(BOOT.BIN). The system boots
> fine with Linux, but now to expose the recently added hardware
> implementation of audio mixer, we are trying to develop the driver
> using the platform driver API. Currently, In our reconfigurable
> hardware, we have 2 channels and a mixer and we want to access those
> individually as some file nodes under /proc FS. The sample code is
> shown below:
>
[..]
It wasn't clear what your problem was, or if you were just asking for
advice, but I will add one comment that will hopefully save you some
debugging time:
> #include
> #include
> #include /*Needed for copy_from_user */
> #include/*Needed for IO Read/Write Functions */
> #include /*Needed for Proc File System Functions
> */
> #include/*Needed for Sequence File Operations */
> #include /*Needed for Platform Driver Functions
> */
>
> /* Define Driver Name */
> #define DRIVER_NAME "myiir"
>
> unsigned long *base_addr; /* Vitual Base Address */
> struct resource *res; /* Device Resource Structure */
> unsigned long remap_size; /* Device Memory Size */
The way this driver is written, you will actually be probed three times,
once per node in the device tree. The drivers' use of global state here
is going to bite you.
[..]
> static int __devinit myiir_probe(struct platform_device *pdev)
> {
> struct proc_dir_entry *myiir_proc_entry[3];
> int ret = 0;
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> if (!res) {
> dev_err(&pdev->dev, "No memory resource\n");
> return -ENODEV;
> }
> remap_size = res->end - res->start + 1;
>
> if (!request_mem_region(res->start, remap_size, pdev->name)) {
> dev_err(&pdev->dev, "Cannot request IO\n");
> return -ENXIO;
> }
>
> base_addr = ioremap(res->start, remap_size);
> if (base_addr == NULL) {
> dev_err(&pdev->dev, "Couldn't ioremap memory at 0x%08lx\n",
> (unsigned long)res->start);
> ret = -ENOMEM;
> goto err_release_region;
> }
[..]
> static const struct of_device_id myiir_of_match[] __devinitconst = {
> {.compatible = "dglnt,myiir-audio-ch0"},
> {.compatible = "dglnt,myiir-audio-ch1"},
> {.compatible = "dglnt,myiir-audio-mix0"},
> {},
> };
Are these really separate IP blocks entirely, or just multiple instances
of the same IP block (perhaps with different parameters used during
synthesis)? If the latter, then they should really share a compatible
string that reflects the name/version of the IP block; handling which
block is which channel should be done at a higher level.
Good luck,
Josh
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: "Time police" - best way to submit?
On Wed, Apr 16, 2014 at 02:27:50PM -0700, Henry Hallam wrote: > Hi, my name is Henry and I'm a kernel newbie. Hello, Henry. > Recently plagued by a perplexing issue where *something* would step > the clock on an important server by exactly 5 minutes at infrequent, > unpredictable intervals, I put together my first kernel module - a > trivial hook into do_settimeofday via a jprobe, that prints the PID, > process name and time adjustment to the kernel message log. > > Here's what I have so far: > https://github.com/henryhallam/timepolice > > Questions: > > 1. Is a module using kprobes/jprobes the right way to do it, vs adding > printks to linux/time/timekeeping.c? Have you taken a look at the various kernel tracing features? I suspect you could do exactly what you want without modifying the kernel at all using the function tracer. Josh ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Question about using spinlock to synchronize between kernel driver and an interrupt handler
On Sat, Feb 01, 2014 at 01:32:49AM -0800, anish singh wrote:
> On Sat, Feb 1, 2014 at 1:15 AM, m silverstri
> wrote:
> > By driver code , I mean the code which set the register values and
> > wait till the values is set (via an interrupt handler) before
> > continues doing something else
> ok so you are looking for below code:
>
>
> some_func()
> {
> set_register_value
> x_variable=0
> wait_for_event*(x_variable);
> }
>
> interrupt_handler(){
> x_variable=1
> wake_up();
> }
>
> request_irq(interrupt_handler);
Please investigate the usage of completions in your driver. See
include/linux/completion.h. It sounds like it fits your usecase nicely.
Josh
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: down_interruptible() return non-zero value once signal is received and trying down_interruptible again in loop return value is always non-zero
On Fri, Oct 18, 2013 at 05:56:41PM +0530, Mushtaq Khan wrote:
> Hi,
>
> In kernel driver, using Semaphore to block on resources (Descriptors and
> memory).
> Semaphore is initialized in locking state using call "init_MTEX_LOCKED()",
> when resources are not available process calls down_interruptible() and
> blocks. Once resources are freed up() is called, and blocked process is
> unblocked. up() is called from interrupt context which frees resources on
> receiving ACK-Interrupt.
> Following is the code snippet for blocking:
> do {
> ret = down_interruptible(sem)
> if (ret == 0) {
> break;
> } else {
> printk("Semaphore is not acquired try again\n");
> continue;
>}
> } while (1);
>
> While loop is used to make sure down_interrptible() is called until process
> acquires the semaphore. If process receives signal, process unblocks from
> down_interrptible() without acquiring the semaphore.
> Issue am seeing is once signal is received under the blocking state, again
> trying to acquire semaphore using down_interruptible() return value is
> always non-zero and process is looping in while loop.
Yes. This happens because there is a signal pending for the calling
thread. If you follow the down_interruptible() code path, you see that
the first thing in the loop in __down_common (kernel/semaphore.c) is
that signal_pending_state() is called to see if there is a pending
signal, and if so, it immediately returns -EINTR.
Using down_interruptible() in the method above is ill-advised. It's
expected that if you are interrupted, you will propagate that
'interrupted' condition to your caller (and eventually back out to
usermode).
Josh
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Check live Virtual Address to Physical Address mappings
On Fri, Apr 19, 2013 at 02:17:58PM +0530, Shraddha Kamat wrote: > I want to see live Virtual Addr. to Physical Addr. mappings for a > process. is it possible to see such mappings ( for e.g. under /proc > etc ..). You may be interested in Documentation/vm/pagemap.txt, which documents the format of /proc//pagemap and friends. Josh ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Question about applying a kernel patch with "git am" received from a mailing list
On Tue, Nov 20, 2012 at 07:53:57PM +0200, Kevin Wilson wrote: > On Tue, Nov 20, 2012 at 7:39 PM, Josh Cartwright wrote: > > On Tue, Nov 20, 2012 at 07:24:28PM +0200, Kevin Wilson wrote: > > > Hi, > > > I am following some kernel mailing lists (netdev and others). > > > I want to be able to save recent patches and to apply the against a git > > > tree. > > > > > > I tried using MUTT client for this. I save the patch (which is almost > > > always inline). > > > > > > Then I run > > > git apply --check patchName > > > and > > > git apply patchName > > > and it applies cleanly. > > > > > > But if I try: > > > git am patchName > > > > > > It gives > > > "Patch format detection failed." > > > > > > Any recommendation what to do to apply a patch > > > with "git am"? > > > > Kevin- > > > > Just use mutt's 'pipe-message' feature, which is bound to '|' by > > default. Pipe the message directly to 'git am'. > > Hi, > Thanks for the quick response! I press "|" , I want to pipe to the > git tree (which is /work/src/net-next). How do I tell pipe that the > path of git tree is there? Simple! Instead of piping to 'git am', pipe to 'cd /work/src/net-next && git am'. Alternatively, run mutt from your source tree. Josh ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Question about applying a kernel patch with "git am" received from a mailing list
On Tue, Nov 20, 2012 at 07:24:28PM +0200, Kevin Wilson wrote: > Hi, > I am following some kernel mailing lists (netdev and others). > I want to be able to save recent patches and to apply the against a git tree. > > I tried using MUTT client for this. I save the patch (which is almost > always inline). > > Then I run > git apply --check patchName > and > git apply patchName > and it applies cleanly. > > But if I try: > git am patchName > > It gives > "Patch format detection failed." > > Any recommendation what to do to apply a patch > with "git am"? Kevin- Just use mutt's 'pipe-message' feature, which is bound to '|' by default. Pipe the message directly to 'git am'. Josh ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: DEFINE Macro
On Thu, Jan 05, 2012 at 07:32:48PM -0800, Fredrick wrote:
> Hi,
>
> I am not able to understand the DEFINE macro used in
> arch/powerpc/kernel/asm-offsets.c
>
> I suppose the DEFINE is present in
> include/linux/kbuild.h
> where it says
> #define DEFINE(sym, val) \
> asm volatile("\n->" #sym " %0 " #val : : "i" (val))
>
> What does the above mean?
This is just a trick to get the offsets of members into a generated header file
asm-offsets.h. The inline assembly does NOT contain valid instructions,
and in fact, asm-offsets.c is never actually assembled into a program.
Instead, the build process generates the assembly language output
asm-offsets.s, and processes it with a sed script to generate
asm-offsets.h.
For example (assume offsetof(struct thread_struct, regs) is 30):
DEFINE(PT_REGS, offsetof(struct thread_struct, regs));
will generate within the assembly language output:
->PT_REGS $30 offsetof(struct thread_struct, regs)
A sed script, executed on the assembly language output will generate a
line in include/generated/asm-offsets.h:
#define PT_REGS 30 /* offsetof(struct thread_struct, regs) */
Thats about it. You can find the exact sed script used, and the make
magic involved in Kbuild (see cmd_offsets).
--
joshc
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: GPIO driver module for Jetway NF98 board
On Wed, Dec 28, 2011 at 06:03:32PM +0100, Joan Pau Beltran wrote: > Thank you very much for your response. > It brings up a lot of useful information. Great, glad it helped! *snip* > Al 22/12/11 01:15, En/na Josh Cartwright ha escrit: > > On Wed, Dec 21, 2011 at 06:34:58PM +0100, Joan Pau Beltran wrote: > > Searching for the symbolic names brings up this document, which looks > > like it may describe in more detail how to use this GPIO interface: > > > > http://download.intel.com/embedded/chipsets/appnote/322174.pdf > > > > After looking at both documents, can you please confirm these ideas: > 1.- The GPIO functionality of the jwnf98 comes from a hardware > device in the chipset called LPC (Low Pin Cout) controller managed > through the LPC Interface Bridge registers (section 9.1 page 366). > This LPC controller provides other functionalities, too. > 2.- The LPC resides in a PCI bus. > 3.- GPIO is managed accessing the registers of the LPC. We should > read from and write to these registers according to the notes in > 13.10 (GPIO_USE_SEL, GPIO_IO_SEL and GPIO_LVL). Not all the GPIOs > are available, only the ones given in the Jetway code. > 4.- The GPIO registers of the LPC are mapped to some I/O port, > starting at the address specified in the GPIOBASE register. From the > first paragraph in section 13.10, page 546: > > The control for the general purpose I/O signals is handled through > > a 128-byte I/O space. The base offset for this space is selected by the > > GPIOBASE > > register. Yes, that is how I understand it, too. > 5.- From Jetway code, it seems that the base address in the GPIOBASE > register described in 13.1.14 is set by the manufacturer to 0x500. > Conversely, the Intel code gets that base address reading the > GPIOBASE register. Note that specific pci functions are used for > that. If Tech Support info is ok, I do not need to do that, and can > simply request the needed i/o ports taking as base offset 0x500. I'd recommend getting the base address of the GPIO region as documented in the Intel manuals, instead of what looks like throw-away testing code from your vendor. Take a peak at drivers/watchdog/iTCO_wdt.c, as this watchdog timer is also accessed through the LPC device. It might give you a few ideas. > If the above points are ok, I have some doubts related with my > previous questions: > > > 1. How should I request/release the ports mentioned in the attached > > > file? Should I use the request_region/release_region functions from > > > linux/ioport.h? In such case, what should I do with the returned > > > struct resource? > > I think I should userequest_region/release_region from > linux/ioport.h, and simply ignore the returned resource, is it ok? I think that would be fine (there are other drivers that currently do this). > > > 3. Should/could I use the test_bit, set_bit, clear_bit functions to > > > get, set the bit in the needed read/write functions I am writing? Or > > > should I use the sequence 'inb - mask the value properly - outb' ? > > Nope, as far as I know these bitops only work with memory operands. > Is this because we use port-based i/o instead of memory-mapped i/o? Yes, precisely. I'd recommend just using standard shift/masking (which looks like what you are already doing). Keep in mind, however, you'll need some locking strategy to ensure that a read-modify-write cycle happens atomically. > Here it goes the code again. While I appreciate it being inlined this time, your mailer seemed to have munged whitespace, such that the code is very difficult to read :(. You may want to see Documentation/email-clients.txt. > The main question is, should the gpio_chip be statically allocated, > or it should be created in the init function and destroyed in the > exit function? If the latter, how to do that? Having one statically allocated gpio_chip object assumes that there will be only one of these chips installed in a system. I think that is a safe assumption to make, so you should be okay. -- joshc ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: GPIO driver module for Jetway NF98 board
(resend, sorry for spam)
On Wed, Dec 21, 2011 at 06:34:58PM +0100, Joan Pau Beltran wrote:
> Hi everyone,
>
> I did not find any existing driver for the GPIO port of the Jetway
> NF98 mini-itx board, so I would like to write a module for that,
> using the gpiolib interface.
>
> Since the board documentation does not include any information about
> the GPIOs, I contacted the Jetway support team. However, the only
> answer was the attached code for Windows (NF98GPIO.c).
> As you can see, it seems clear how to set the pin states for output,
> but not how to read them in input mode. I asked again and the
> response was (literally):
> >input sample code:
> >{
> >data= ISA_RW(GPIO_BASE[pin]+0x2,highlow< >}
> >//final exit SIO
> >outp(INDEX_PORT,0xaa);
> >return data;
> It makes no sense, and it is very upsetting.
> I would try to read from the same address used for output, but this
> is just an idea to be tested.
I think you're on the right track. In researching this board a little
more, I was able to uncover some information. For the sake of
learning, I've included my steps to discovery here:
>From Jetway's website (http://www.jetwaycomputer.com/NF98.html), I found
that the chipset used in the board is an Intel QM57.
Searching for datasheets for the Intel QM57 brought me to Intel's site
(http://www.intel.com/content/www/us/en/chipsets/5-chipset-3400-chipset-datasheet.html).
Searching the document for GPIO, I found section 5.15.4, "GPIO Registers
Lockdown". The content of the text portion of the section didn't seem
all that relevant, but there is a description of a register set that
seems to match up with the values in your attached example:
00h: GPIO_USE_SEL[31:0]
04h: GP_IO_SEL[31:0]
0Ch: GP_LVL[31:0]
28h: GPI_NMI_EN[15:0]
2Ch: GPI_INV[31:0]
30h: GPIO_USE_SEL2[63:32]
34h: GPI_IO_SEL2[63:32]
38h: GP_LVL2[63:32]
40h: GPIO_USE_SEL3[95:64]
44h: GPI_IO_SEL3[95:64]
48h: GP_LVL3[95:64]
60h: GP_RST_SEL[31:0]
64h: GP_RST_SEL2[63:32]
68h: GP_RST_SEL3[95:64]
Searching for the symbolic names brings up this document, which looks
like it may describe in more detail how to use this GPIO interface:
http://download.intel.com/embedded/chipsets/appnote/322174.pdf
> Since I have not written any kernel module before, after reading the
> pertinent documentation about memory management, i/o port access, and
> gpiolib, I have some questions.
>
> 1. How should I request/release the ports mentioned in the attached
> file? Should I use the request_region/release_region functions from
> linux/ioport.h? In such case, what should I do with the returned
> struct resource?
>
> 2. I suppose that I should use the same addresses given by the
> support team, although their code is for windows. Is it ok?
The above document seemed to insinuate that the actual IO region used
for GPIO access isn't statically allocated, but rather allocated during
PCI enumeration for a LPC device. If this is the case, you have an
additional question you need answered:
- What is the best way to get the base address for accessing these
GPIOs?
(the example code provided in the above document uses pci_get_device
which sounds clunky...)
Actually, with some further grepping I found that a lot of this
infrastructure may already be available to you. See
drivers/mfd/lpc_sch.c and drivers/gpio/sch_gpio.c. Not sure what it
would take to get it working with your setup, but it should give you a
good starting point.
> 3. Should/could I use the test_bit, set_bit, clear_bit functions to
> get, set the bit in the needed read/write functions I am writing? Or
> should I use the sequence 'inb - mask the value properly - outb' ?
Nope, as far as I know these bitops only work with memory operands.
> The second file attached is an skeleton of the module I am trying to
> write, any comments or suggestions are welcome.
(in the future, please inline any code you'd like reviewed)
Good luck!
--
joshc
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: can i simply "re-version" the kernel down to 2.x?
On Fri, Aug 05, 2011 at 10:36:00AM -0400, Robert P. J. Day wrote:
>
> for reasons that don't need explaining, i need to rebuild my current
> 3.0.0... kernel so that it returns a "uname" version number of
> "2.whatever". i simply have an app i want to run that checks the
> output of "uname" and if it doesn't see a major number of "2", it goes
> a bit squirrelly.
If it is just one poorly written app you are trying to deal with, it
might just be easier to create a wrapper dll that traps the glibc uname
wrapper and hijacks the returned version. Something like this:
--- /dev/null 2011-08-02 20:23:03.358999850 -0500
+++ b/trapuname.c 2011-08-05 22:45:02.0 -0500
@@ -0,0 +1,43 @@
+/* trapuname: tool to fake uname release
+ * Copyright (C) 2011 Josh Cartwright
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
USA.
+ */
+#define _GNU_SOURCE
+#include
+#include
+#include
+#include
+#include
+
+int uname(struct utsname *u)
+{
+ const char *err;
+ int ret;
+ int (*old_uname)(struct utsname *u);
+
+ dlerror();
+ old_uname = dlsym(RTLD_NEXT, "uname");
+
+ if ((err = dlerror())) {
+ fprintf(stderr, "Unable to load uname: %s\n", err);
+ exit(EXIT_FAILURE);
+ }
+
+ if (!(ret = old_uname(u)))
+ strcpy(u->release, "2.6.40");
+
+ return ret;
+}
Build it into a dynamic library, the use LD_PRELOAD to load it before
your application is run:
$ gcc -shared -fPIC trapuname.c -ldl -o libtrapuname.so
$ LD_PRELOAD=./libtrapuname.so stupidapp
At least this way, you won't be carting around a local kernel patch just
for a version change :\.
--
joshc
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: how does fork() copy threads of a process in multi-processor (SMP)
On Thu, Mar 10, 2011 at 11:55:35PM +0700, Mulyadi Santosa wrote: > Hi... > > On Thu, Mar 10, 2011 at 22:05, lalit mohan tripathi > wrote: > > I've a general question: In Multiprocessor (Multi-Core) (SMP) > > environment how does fork system call (do_fork() related code) > > maintain the synchronization in case the threads of a process are > > running on different processors? E.g. it can happen that the fork() > > is called by cpu-0 thread and other thread of same process is > > executing on cpu-1. > > well, AFAIK, the newly born child, at least when they are just about > to kick in into the run queue (in any CPU), is actually still inside > the parent's code path. Or in simpler word, they are still bound in > the same core/processor they are created. Therefore, there's no > problem regarding task struct duplication etc Also, please keep in mind that fork() does NOT cause all the threads of the parent process to propogate to the child process. Only the thread that called fork() is duplicated. From `man 2 fork': * The child process is created with a single thread -- the one that called fork(). The entire virtual address space of the parent is replicated in the child, including the states of mutexes, condition variables, and other pthreads objects; the use of pthread_atfork(3) may be helpful for dealing with problems that this can cause. -- joshc ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: To schedule a process?
On Sun, Feb 27, 2011 at 07:16:31AM -0800, kashish bhatia wrote: > Suppose if I wrote a simple c program but I want to execute this program > everyday at a > specific time ( say at 12 p.m) . > > > Is there any command by which I can schedule the execution of any > process(a.out in this case)? This really isn't a question meant for kernelnewbies, but regardless 'cron' is the tool you are looking for. There are several implementations out there; google should point you in the right direction. -- joshc ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
