Re: [PATCH 2.6.13-rc6 1/2] New Syscall: get rlimits of any process (update)
On Thu, 18 Aug 2005, Alan Cox wrote: > > Also some documention for specific services show that there is a need to > > adjust rlimits per process at runtime, e.g.: > > http://www.squid-cache.org/Doc/FAQ/FAQ-11.html#ss11.4 > > http://slacksite.com/apache/logging.html > > http://staff.in2.hr/denis/oracle/10g1install_fedora3_en.html#n2 > > Perhaps those application authors should provide a management interface > to do so within the soft limit range at least. Its not clear to me that > growing the fd array on a process is even safe. Some programs do size > arrays at startup after querying the rlimit data. This is getting hung up on one particular example, while missing the bigger picture. Being able to set rlimits for other processes is useful in general, just as things like nice() and sched_setscheduler() are. Maybe it is reducing max RSS on certain processes and increasing it on other processes, so that the memory tends to be used for higher-priority processes. Maybe it is setting max cpu time to T+5 minutes, so that if a seemingly stuck process has not exited in five minutes, it will die. Maybe it is limiting the number of processes that a daemon can spawn. In addition, it's not always practical to have application authors provide a management interface. You're right that there can be potential problems with adjusting rlimits on the fly, but that doesn't seem like a sufficient reason to avoid including the feature. Best, -- Elliot Pioneers get the Arrows. Settlers get the Land. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Driver for Casio Cassiopia Fiva touchscreen, help with conversionto 2.4
Available at http://people.redhat.com/~sopwith/fidmour-linux.c is a driver for the touch screen used on the Cassiopia Fiva MPC-501 pen computer. It is a rather Bad Hack (seeing as it was built rather blindly to mimic the behaviour of the Windows driver, and has IRQ/port hardcoded in), but it works for me with the 2.2.16 kernel. The device outputs 5 byte packets - 1 status byte, 2 bytes each for X & Y coordinates. The devel branch of GTK+ has support for /dev/fidmour in the Linux framebuffer backend (gtk+/gdk/linux-fb/gdkmouse-fb.c), should you wish to see a code sample. I'm wondering if anyone has a resource that would provide information on porting this driver to the 2.4 kernel. I would welcome comments on this driver, or on the MPC-501 and Linux in general. Bonus points to anyone who actually understands why the driver works and how the hardware works. :) Hope this helps, -- Elliot Who me? I just wander from room to room. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ANNOUNCE: Linux Kernel ORB: kORBit
On 14 Dec 2000, Michael Livshin wrote: > this might be because the Bell Labs folks don't like RPC in general > when network latencies become involved? I'm guessing. > > 'cause CORBA is still pretty much objectified RPC, as far as I know. > I don't think you want to abstract the network out just like that when > dealing with kernels. OK, since everyone seems to want to argue about this on orbit-list for some reason, my $0.02: CORBA/IIOP is saner than SunRPC in a lot of ways, and it's not too horribly more complicated to implement a barebones ORB than a barebones SunRPC impl. Comments about CORBA being too slow are nonsense - it's just that a few crackheads have tried to stick ORBit in the kernel as a global IPC mechanism, which it really is not suitable for. CORBA has its place, and a GIOP mapping to a kernel-friendly IPC mechanism (instead of TCP/IP) would certainly make it more useful in the kernel, but generic mechanisms such as CORBA cannot by definition be as fast as IPC mechanisms optimized for a specific task. People like Al Viro, who haven't written GNOME programs of any size and certainly don't have mounds of in-depth knowledge of it, should probably shut up about about its API & design. :) TTFN, -- Elliot No new ideas for my .sig, and Alan told me my old one was an urban myth, so just ignore this. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
