more SAK stuff
Quoted 2 lines
Quoted 2 lines
(a) It does less, namely will not kill processes with uid 0. Ted, any objections?
Alan:
Quoted 2 lines
That breaks the security guarantee. Suppose I use a setuid app to confuse you into doing something ?
On second thoughts I agree. Here is the patch without test for p->uid.
Andries
linux/drivers/char/keyboard.c renamed from linux-2.4.6-pre8/linux/drivers/char/keyboard.c +2 -0
@@ -506,6 +506,8 @@* them properly. */ +if (!tty && ttytab && ttytab[0 ] && ttytab[0 ]->driver_data) + tty = ttytab[0 ];do_SAK (tty);reset_vc (fg_console);#if 0
linux/drivers/char/tty_io.c renamed from linux-2.4.6-pre8/linux/drivers/char/tty_io.c +36 -10
82 lines not on this page · raw message
Building multipart modules with subdirectories...
This question has to do with the kernel build system as it relates to building a driver both as static and as a module. I have a solution, but I don't like it. Please read on...
I have driver that is rather complex and in order to maintain it, the module is broke up into 17 different subdirectories. I am maintaining it and I am trying to integrate it into the kernel build system. No, I am not the original architect. Regardless, in the top level Makefile of my driver directory I have the statement:
subdir-$(CONFIG_FOO_DRV) += $(17 directories' names)
When the module is built, the 'foodrv.o' object is placed in the top level directory. The problem is that when a 'make modules_install' is done, it uses the directories defined in 'subdir-$(CONFIG_FOO_DRV)' and proceeds to fail installing in each of the subdirectories because there is no target in their makefiles and nor should there be since their objects are part of the top-level module object.
I could use the 'subdir-' directive above only when I am statically linking in the driver, hence place it in an 'if' statement. Then when I build the driver as a module, I manually enter each directory and do a 'make -C <dir> modules'. However, since the 'subdir-' definition would be missing if I am building as a module, no '.depend' files are generated in my subdirectories when I do a 'make dep' which means if I change a critical header file in my driver's common include directory, the .c files using it will not be rebuilt! If I could override the 'modules_install' target in each of my subdirectories makefiles the problem would be solved. This is possible according to a solution in the info pages for make, but it requires me to create a GNUmakefile in each of my directories. Can someone perhaps give me some ideas for this dilemna? Thanks.
-Steve
Signature · 1 line
Steven J. Hill - Embedded SW Engineer
Re: Building multipart modules with subdirectories...
Quoted 3 lines · Steven J. Hill
I have driver that is rather complex and in order to maintain it, the module is broke up into 17 different subdirectories. I am maintaining it and I am trying to integrate it into the kernel build system.
I had the same problem with XFS. Code split over multiple directories, code in the sub directories had to be compiled for modules but not be installed as a module, instead the sub directory objects are linked into the parent directory then the whole is installed as one module. Is that your problem?
In the parent Makefile
--------
O_TARGET := foo.o
obj-m := $(O_TARGET)foo_subdirs := sub directory list subdir-$(CONFIG_FOO_DRV) += $(foo_subdirs) obj-y += $(foreach dir,$(foo_subdirs),$(dir)/$(dir).o)
....
include $(TOPDIR)/Rules.make
# This is really nasty, but Rules.make was never designed for multi directory
# modules and it can race on parallel build. Keith Owens. foo.o: $(patsubst %,_modsubdir_%,$(subdir-m))
--------
In each sub directory
--------
O_TARGET := $(notdir $(CURDIR)).o
ifneq ($(MAKECMDGOALS),modules_install)
obj-m := $(O_TARGET)
endif
obj-y += list of sub directory objects
--------
This is so much easier in kbuild 2.5 :).