Re: System call vs POSIX call
On Thu, Aug 16, 2018 at 03:44:49PM -0400, valdis.kletni...@vt.edu wrote: > On Thu, 16 Aug 2018 16:29:29 -, Nicholas Mc Guire said: > > > Note that you can do system calls directly with system() but that is > > generaly not how you do it - you to through the glibc calls > > which do some checks before invoking the actual system call. > > system() does a fork/exec of a process. > > syscall() issues an arbitrary system call, but all marshalling of > parameters and return codes becomes your problem yup - sorry - my bad - thats what I actually had in mind but did not check. thanks for your correction ! thx! hofrat ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: System call vs POSIX call
On Thu, 2018-08-16 at 15:44 -0400, valdis.kletni...@vt.edu wrote: > On Thu, 16 Aug 2018 16:29:29 -, Nicholas Mc Guire said: [...] Generally, POSIX specifies a API and doesn't really care it it's a real syscall (which crosses the border of user- and kernel-space by definition), a pure-user-space function or some mixture. > > Note that you can do system calls directly with system() but that is > > generaly not how you do it - you to through the glibc calls > > which do some checks before invoking the actual system call. > > system() does a fork/exec of a process. ... via `/bin/sh -c` so it's actually (at least) 2 of both. > syscall() issues an arbitrary system call, but all marshalling of > parameters and return codes becomes your problem ... as well as the availability of that syscall at runtime (and glibc has a lot of compatibility/emulation in that direction). Not everyone everywhere has a (somewhat) recent kernel. MfG, Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: System call vs POSIX call
On Thu, 16 Aug 2018 16:29:29 -, Nicholas Mc Guire said: > Note that you can do system calls directly with system() but that is > generaly not how you do it - you to through the glibc calls > which do some checks before invoking the actual system call. system() does a fork/exec of a process. syscall() issues an arbitrary system call, but all marshalling of parameters and return codes becomes your problem pgpb84q0Wz515.pgp Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: GPIO consumer interface and DT
> You or someone else first need to define device tree bindings > in Documention/devicetree/bindings/usb/* somwhere, then augment > the driver to use these bindings, including the right name for > the GPIO line, when using the devm_gpiod_get(). OK, I will try to start a discussion about this. > I wonder how you're testing this though. I don't have this equipment to be honest. Once work is done I count on kindness of interested people who actually have it and are able to test the patch on the target. Is there any other way? Thanks, Arek ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: System call vs POSIX call
On Thu, Aug 16, 2018 at 09:51:05PM +0530, Subhashini Rao Beerisetty wrote: > Hi All, > > I'm trying to get the difference between system call and POSIX call. System > calls are user mode API's (open(), close(), ioctl(),...) gets the kernel > service via software interrupt. What about POSIX calls and how it differs > with the system call.? Can anyone clarify me on this. glibc is the library that connects user-space libs/apps to the system call interface (unistd.h basically) so if you do an open() in user-space you are calling glibc and that can call sys_open() but there are POSIX calls that will not necessarily do a system call if they can handle the request with available resources or with cached data. So there is no 1:1 mapping at runtime from POSIX call to system call - and there can be multiple POSIX calls that map to a single system call (e.g. printf -> write) Note that you can do system calls directly with system() but that is generaly not how you do it - you to through the glibc calls which do some checks before invoking the actual system call. Does that clarify it ? thx! hofrat ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
System call vs POSIX call
Hi All, I'm trying to get the difference between system call and POSIX call. System calls are user mode API's (open(), close(), ioctl(),...) gets the kernel service via software interrupt. What about POSIX calls and how it differs with the system call.? Can anyone clarify me on this. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: GPIO consumer interface and DT
On Thu, Aug 16, 2018 at 12:11 AM Arkadiusz Lis wrote: > What I learned > from Documentation/driver-api/gpio/board.rst is this string should be > equal to prefix in -gpios node in device tree. > For example: in file drivers/i2c/busses/i2c-gpio.c author gets gpio > descriptor with con_ids 'sda' and 'scl'. They are described in > Documentation/devicetree/bindings/i2c/i2c-gpio.txt as required > properties. You got it right. > In my case I didn't find bindings for emxx_udc driver and I don't know > what string should I insert: > gpiod = devm_gpiod_get(udc->dev, "DT_GPIOS_NAME", GPIOD_IN); // > "DT_GPIOS_NAME" is a placeholder This driver is not yet converted to use device tree so there is no way you can know this property name before bindings are established. You or someone else first need to define device tree bindings in Documention/devicetree/bindings/usb/* somwhere, then augment the driver to use these bindings, including the right name for the GPIO line, when using the devm_gpiod_get(). Pretty certainly the chosen GPIO name will be "vbus-gpios" in this case so you will pass "vbus" as name. But that needs to first be discussed by the DT bindings mailing list. I wonder how you're testing this though. Yours, Linus Walleij ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: How to assess how much stack space kernel function may use?
On Thu, Aug 16, 2018 at 04:24:33PM +0300, Lev Olshvang wrote: > Hello all > > I am writing kernel module function that calls for vfs function , so I am not > aware how deep kernel stack can grow due to my calls > > I need to take 512 bytes for some processing, and I know kernel stack is 4K > only. Ick don't do that, fix your function to not take so much stack space. That's the correct fix, do't try to "figure out" how much stack is left, it will not be the same for different arches or different paths through the vfs layer. good luck! greg k-h ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
How to assess how much stack space kernel function may use?
Hello all I am writing kernel module function that calls for vfs function , so I am not aware how deep kernel stack can grow due to my calls I need to take 512 bytes for some processing, and I know kernel stack is 4K only. My function is also part of calling chain, so I do not know how much stack is used before my function is called. What dara can I get from kernel during compilation and run about stack utiilizaton to help me in estimation ? Lev ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Is there any way to show local var when using crash to analyse coredump?
Hi list, When using gdb, we can use "frame" command to select which layer in the back trace to debug, and then we can use "print" command to print local var within this layer. But I found that these two commands does not work in crash tool, is there any way to solve it? Thanks Larry___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
