Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3
On 3/7/07, Ingo Molnar <[EMAIL PROTECTED]> wrote: * Kirk Kuchov <[EMAIL PROTECTED]> wrote: > I don't believe I'm wasting my time explaining this. They don't exist > as /dev/null, they are just fucking _LINKS_. [...] > > Either stop flaming kernel developers or become one. It is that > > simple. > > If I were to become a kernel developer I would stick with FreeBSD. > [...] Hey, really, this is an excellent idea: what a boon you could become to FreeBSD, again! How much they must be longing for your insightful feedback, how much they must be missing your charming style and tactful approach! I bet they'll want to print your mails out, frame them and hang them over their fireplace, to remember the good old days on cold snowy winter days, with warmth in their hearts! Please? http://www.totallytom.com/thecureforgayness.html -- Kirk Kuchov - 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: Trading Places (was: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3)
On 3/7/07, Al Boldi <[EMAIL PROTECTED]> wrote: Kirk Kuchov wrote: > > Either stop flaming kernel developers or become one. It is that > > simple. > > If I were to become a kernel developer I would stick with FreeBSD. At > least they have kqueue for about seven years now. I have been playing with this thought for quite some time. The question is, can I just use FreeBSD as a drop-in kernel replacement for Linux, or do I have to leave all the GNU/Linux distributions behind as well? http://www.debian.org/ports/kfreebsd-gnu/ -- Kirk Kuchov - 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: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3
On 3/6/07, Pavel Machek <[EMAIL PROTECTED]> wrote: > >As for why common abstractions like file are a good thing, think about why > >having "/dev/null" is cleaner that having a special plug DEVNULL_FD fd > >value to be plugged everywhere, > > This is a stupid comparaison. By your logic we should also have /dev/stdin, > /dev/stdout and /dev/stderr. Bzzt, wrong. We have them. [EMAIL PROTECTED]:~$ ls -al /dev/std* lrwxrwxrwx 1 root root 4 Nov 12 2003 /dev/stderr -> fd/2 lrwxrwxrwx 1 root root 4 Nov 12 2003 /dev/stdin -> fd/0 lrwxrwxrwx 1 root root 4 Nov 12 2003 /dev/stdout -> fd/1 [EMAIL PROTECTED]:~$ ls -al /proc/self/fd total 0 dr-x-- 2 pavel users 0 Mar 6 09:18 . dr-xr-xr-x 4 pavel users 0 Mar 6 09:18 .. lrwx-- 1 pavel users 64 Mar 6 09:18 0 -> /dev/ttyp2 lrwx-- 1 pavel users 64 Mar 6 09:18 1 -> /dev/ttyp2 lrwx-- 1 pavel users 64 Mar 6 09:18 2 -> /dev/ttyp2 lr-x-- 1 pavel users 64 Mar 6 09:18 3 -> /proc/2299/fd [EMAIL PROTECTED]:~$ I don't believe I'm wasting my time explaining this. They don't exist as /dev/null, they are just fucking _LINKS_. I could even "ln -s /proc/self/fd/0 sucker". A real /dev/stdout can/could even exist, but that's not the point! It remains a stupid comparison because /dev/stdin/stderr/whatever "must" be plugged, else how could a process write to stdout/stderr that it coud'nt open it ? The way things are is not because it's cleaner to have it as a file but because it's the only sane way. /dev/null is not a must have, it's mainly used for redirecting purposes. A sys_nullify(fileno(stdout)) would rule out almost any use of /dev/null. > >As for why common abstractions like file are a good thing, think about why > >having "/dev/null" is cleaner that having a special plug DEVNULL_FD fd > >value to be plugged everywhere, > >But here the list could be almost endless. > >And please don't start the, they don't scale or they need heavy file > >binding tossfeast. They scale as well as the interface that will receive > >them (poll, select, epoll). Heavy file binding what? 100 or so bytes for > >the struct file? How many signal/timer fd are you gonna have? Like 100K? > >Really moot argument when opposed to the benefit of being compatible with > >existing POSIX interfaces and being more Unix friendly. > > So why the HELL don't we have those yet? Why haven't you designed > epoll with those in mind? Why don't you back your claims with patches? > (I'm not a kernel developer.) Either stop flaming kernel developers or become one. It is that simple. If I were to become a kernel developer I would stick with FreeBSD. At least they have kqueue for about seven years now. -- Kirk Kuchov - 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: [patch 00/13] Syslets, Threadlets, generic AIO support, v3
On 3/6/07, Pavel Machek [EMAIL PROTECTED] wrote: As for why common abstractions like file are a good thing, think about why having /dev/null is cleaner that having a special plug DEVNULL_FD fd value to be plugged everywhere, This is a stupid comparaison. By your logic we should also have /dev/stdin, /dev/stdout and /dev/stderr. Bzzt, wrong. We have them. [EMAIL PROTECTED]:~$ ls -al /dev/std* lrwxrwxrwx 1 root root 4 Nov 12 2003 /dev/stderr - fd/2 lrwxrwxrwx 1 root root 4 Nov 12 2003 /dev/stdin - fd/0 lrwxrwxrwx 1 root root 4 Nov 12 2003 /dev/stdout - fd/1 [EMAIL PROTECTED]:~$ ls -al /proc/self/fd total 0 dr-x-- 2 pavel users 0 Mar 6 09:18 . dr-xr-xr-x 4 pavel users 0 Mar 6 09:18 .. lrwx-- 1 pavel users 64 Mar 6 09:18 0 - /dev/ttyp2 lrwx-- 1 pavel users 64 Mar 6 09:18 1 - /dev/ttyp2 lrwx-- 1 pavel users 64 Mar 6 09:18 2 - /dev/ttyp2 lr-x-- 1 pavel users 64 Mar 6 09:18 3 - /proc/2299/fd [EMAIL PROTECTED]:~$ I don't believe I'm wasting my time explaining this. They don't exist as /dev/null, they are just fucking _LINKS_. I could even ln -s /proc/self/fd/0 sucker. A real /dev/stdout can/could even exist, but that's not the point! It remains a stupid comparison because /dev/stdin/stderr/whatever must be plugged, else how could a process write to stdout/stderr that it coud'nt open it ? The way things are is not because it's cleaner to have it as a file but because it's the only sane way. /dev/null is not a must have, it's mainly used for redirecting purposes. A sys_nullify(fileno(stdout)) would rule out almost any use of /dev/null. As for why common abstractions like file are a good thing, think about why having /dev/null is cleaner that having a special plug DEVNULL_FD fd value to be plugged everywhere, But here the list could be almost endless. And please don't start the, they don't scale or they need heavy file binding tossfeast. They scale as well as the interface that will receive them (poll, select, epoll). Heavy file binding what? 100 or so bytes for the struct file? How many signal/timer fd are you gonna have? Like 100K? Really moot argument when opposed to the benefit of being compatible with existing POSIX interfaces and being more Unix friendly. So why the HELL don't we have those yet? Why haven't you designed epoll with those in mind? Why don't you back your claims with patches? (I'm not a kernel developer.) Either stop flaming kernel developers or become one. It is that simple. If I were to become a kernel developer I would stick with FreeBSD. At least they have kqueue for about seven years now. -- Kirk Kuchov - 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: Trading Places (was: [patch 00/13] Syslets, Threadlets, generic AIO support, v3)
On 3/7/07, Al Boldi [EMAIL PROTECTED] wrote: Kirk Kuchov wrote: Either stop flaming kernel developers or become one. It is that simple. If I were to become a kernel developer I would stick with FreeBSD. At least they have kqueue for about seven years now. I have been playing with this thought for quite some time. The question is, can I just use FreeBSD as a drop-in kernel replacement for Linux, or do I have to leave all the GNU/Linux distributions behind as well? http://www.debian.org/ports/kfreebsd-gnu/ -- Kirk Kuchov - 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: [patch 00/13] Syslets, Threadlets, generic AIO support, v3
On 3/7/07, Ingo Molnar [EMAIL PROTECTED] wrote: * Kirk Kuchov [EMAIL PROTECTED] wrote: I don't believe I'm wasting my time explaining this. They don't exist as /dev/null, they are just fucking _LINKS_. [...] Either stop flaming kernel developers or become one. It is that simple. If I were to become a kernel developer I would stick with FreeBSD. [...] Hey, really, this is an excellent idea: what a boon you could become to FreeBSD, again! How much they must be longing for your insightful feedback, how much they must be missing your charming style and tactful approach! I bet they'll want to print your mails out, frame them and hang them over their fireplace, to remember the good old days on cold snowy winter days, with warmth in their hearts! Please? http://www.totallytom.com/thecureforgayness.html -- Kirk Kuchov - 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: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3
On 3/4/07, Davide Libenzi wrote: On Sun, 4 Mar 2007, Kirk Kuchov wrote: > On 3/3/07, Davide Libenzi wrote: > > > > > > Those *other* (tons?!?) interfaces can be created *when* the need comes > > (see Linus signalfd [1] example to show how urgent that was). *When* > > the need comes, they will work with existing POSIX interfaces, without > > requiring your own just-another event interface. Those other interfaces > > could also be more easily adopted by other Unix cousins, because of > > the fact that they rely on existing POSIX interfaces. > > Please stop with this crap, this chicken or the egg argument of yours is utter > BULLSHIT! Wow, wow, fella! You _deinitely_ cannot afford rudeness here. I don't give a shit. You started bad, and you end even worse. By listing a some APIs that will work only with epoll. As I said already, and as it was listed in the thread I posted the link, something like: int signalfd(...); // Linus initial interface would be perfectly fine int timerfd(...); // Open ... int eventfd(...); // [1] Will work *even* with standard POSIX select/poll. 95% or more of the software does not have scalability issues, and select/poll are more portable and easy to use for simple stuff. On top of that, as I already said, they are *confined* interfaces that could be more easily adopted by other Unixes (if they are 100-200 lines on Linux, don't expect them to be a lot more on other Unixes) [2]. We *already* have the infrastructure inside Linux to deliver events (f_op->poll subsystem), how about we use that instead of just-another way? [3] Man you're so full of shit, your eyes are brown. NOBODY cares about select/poll or that the interfaces are going to be adopted by other Unixes. This issue has already been solved by then YEARS ago. What I want (and a ton of other users) is a SIMPLE and generic way to receive events from _MULTIPLE_multiple sources. I don't care about kernel-level portability, easiness or whatever, the linux kernel developers are good at not knowing what their users want. As for why common abstractions like file are a good thing, think about why having "/dev/null" is cleaner that having a special plug DEVNULL_FD fd value to be plugged everywhere, This is a stupid comparaison. By your logic we should also have /dev/stdin, /dev/stdout and /dev/stderr. or why I can use find/grep/cat/echo/... to look/edit at my configuration inside /proc, instead of using a frigging registry editor. Yet another stupid comparaison, /proc is a MESS! Almost as worse as the registry. Linux now has three pieces of crap for configuration/information: /proc, sysfs and sysctl. Nobody knows exactly what should go into each one of those. Crap design at it's best. But here the list could be almost endless. And please don't start the, they don't scale or they need heavy file binding tossfeast. They scale as well as the interface that will receive them (poll, select, epoll). Heavy file binding what? 100 or so bytes for the struct file? How many signal/timer fd are you gonna have? Like 100K? Really moot argument when opposed to the benefit of being compatible with existing POSIX interfaces and being more Unix friendly. So why the HELL don't we have those yet? Why haven't you designed epoll with those in mind? Why don't you back your claims with patches? (I'm not a kernel developer.) As for the AIO stuff, if threadlets/syslets will prove effective, you can host an epoll_wait over a syslet/threadlet. Or, if the 3 lines of userspace code needed to do that, fall inside your definition of "kludge", we can even find a way to bridge the two. I don't care about threadlets in this context, I just want to wait for EVENTS from MULTIPLE sources WITHOUT mixing signals and other crap. Your arrogance is amusing, stop pushing narrow-minded beliefs down the throats of all Linux users. Kqueue, event ports, WaitForMultipleObjects, epoll with multiple sources. That's what users want, not yet another syscall/whatever hack. Now, how about we focus on the topic of this thread? [1] This could be an idea. People already uses pipes for this, but pipes has some memory overhead inside the kernel (plus use two fds) that could, if really felt necessary, be avoided. Yet another hack!! 64kiB of space just to push some user events around. Great idea! [2] This is how those kind of interfaces should be designed. Modular, re-usable, file-based interfaces, whose acceptance is not linked into slurping-in a whole new interface with tenths of sub, interface-only, objects. And from this POV, epoll is the friendlier. Who said I want yet another interface? I just fucking want to receive events from MULTIPLE sources through epoll. With or without a fd! My anger and frustration is that we can get past this SIMPLE need! [3] Notice the similarity between threadlets/syslets and epoll? They enable pretty darn
Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3
On 3/3/07, Davide Libenzi wrote: Those *other* (tons?!?) interfaces can be created *when* the need comes (see Linus signalfd [1] example to show how urgent that was). *When* the need comes, they will work with existing POSIX interfaces, without requiring your own just-another event interface. Those other interfaces could also be more easily adopted by other Unix cousins, because of the fact that they rely on existing POSIX interfaces. Please stop with this crap, this chicken or the egg argument of yours is utter BULLSHIT! Just because Linux doesn't have a decent kernel event notification mechanism it does not mean that users don't need. Nobody cared about Linus's signalfd because it wasn't mainline. Look at any event notification libraries out there, it makes me sick how much kludge they have to go thru to get near the same functionality of kqueue on Linux. Solaris has the Event Ports mechanism since 2003. FreeBSD, NetBSD, OpenBSD and Mac OS X support kqueue since around 2000. Windows has had event notification for ages now. These _facilities_ are all widely used, given the platforms popularity. So here we are, 2007. epoll() works with files, pipes, sockets, inotify and anything pollable (file descriptors) but aio, timers, signals and user-defined event. Can we please get those working with epoll ? Something as simple as: struct epoll_event ev; ev.events = EV_TIMER | EPOLLONESHOT; ev.data.u64 = 1000; /* timeout */ epoll_ctl(epfd, EPOLL_CTL_ADD, 0 /* ignored */, ); or struct sigevent ev; ev.sigev_notify = SIGEV_EPOLL; ev.sigev_signo = epfd; ev.sigev_value = timer_create(CLOCK_MONOTONIC, , ); AIO: struct sigevent ev; int fd = io_setup(..); /* oh boy, I wish... but it works */ ev.events = EV_AIO | EPOLLONESHOT; /* event.data.ptr returns pointer to the iocb */ epoll_ctl(epfd, EPOLL_CTL_ADD, fd, ); or struct iocb iocb; iocb.aio_fildes = fileno(stdin); iocb.aio_lio_opcode = IO_CMD_PREAD; iocb.c.notify = IO_NOTIFY_EPOLL; /* __pad3/4 */ Would this be acceptable? Can we finally move on? -- Kirk Kuchov - 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: [patch 00/13] Syslets, Threadlets, generic AIO support, v3
On 3/3/07, Davide Libenzi davidel@xmailserver.org wrote: snip Those *other* (tons?!?) interfaces can be created *when* the need comes (see Linus signalfd [1] example to show how urgent that was). *When* the need comes, they will work with existing POSIX interfaces, without requiring your own just-another event interface. Those other interfaces could also be more easily adopted by other Unix cousins, because of the fact that they rely on existing POSIX interfaces. Please stop with this crap, this chicken or the egg argument of yours is utter BULLSHIT! Just because Linux doesn't have a decent kernel event notification mechanism it does not mean that users don't need. Nobody cared about Linus's signalfd because it wasn't mainline. Look at any event notification libraries out there, it makes me sick how much kludge they have to go thru to get near the same functionality of kqueue on Linux. Solaris has the Event Ports mechanism since 2003. FreeBSD, NetBSD, OpenBSD and Mac OS X support kqueue since around 2000. Windows has had event notification for ages now. These _facilities_ are all widely used, given the platforms popularity. So here we are, 2007. epoll() works with files, pipes, sockets, inotify and anything pollable (file descriptors) but aio, timers, signals and user-defined event. Can we please get those working with epoll ? Something as simple as: struct epoll_event ev; ev.events = EV_TIMER | EPOLLONESHOT; ev.data.u64 = 1000; /* timeout */ epoll_ctl(epfd, EPOLL_CTL_ADD, 0 /* ignored */, ev); or struct sigevent ev; ev.sigev_notify = SIGEV_EPOLL; ev.sigev_signo = epfd; ev.sigev_value = ev; timer_create(CLOCK_MONOTONIC, ev, timerid); AIO: struct sigevent ev; int fd = io_setup(..); /* oh boy, I wish... but it works */ ev.events = EV_AIO | EPOLLONESHOT; /* event.data.ptr returns pointer to the iocb */ epoll_ctl(epfd, EPOLL_CTL_ADD, fd, ev); or struct iocb iocb; iocb.aio_fildes = fileno(stdin); iocb.aio_lio_opcode = IO_CMD_PREAD; iocb.c.notify = IO_NOTIFY_EPOLL; /* __pad3/4 */ Would this be acceptable? Can we finally move on? -- Kirk Kuchov - 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: [patch 00/13] Syslets, Threadlets, generic AIO support, v3
On 3/4/07, Davide Libenzi davidel@xmailserver.org wrote: On Sun, 4 Mar 2007, Kirk Kuchov wrote: On 3/3/07, Davide Libenzi davidel@xmailserver.org wrote: snip Those *other* (tons?!?) interfaces can be created *when* the need comes (see Linus signalfd [1] example to show how urgent that was). *When* the need comes, they will work with existing POSIX interfaces, without requiring your own just-another event interface. Those other interfaces could also be more easily adopted by other Unix cousins, because of the fact that they rely on existing POSIX interfaces. Please stop with this crap, this chicken or the egg argument of yours is utter BULLSHIT! Wow, wow, fella! You _deinitely_ cannot afford rudeness here. I don't give a shit. You started bad, and you end even worse. By listing a some APIs that will work only with epoll. As I said already, and as it was listed in the thread I posted the link, something like: int signalfd(...); // Linus initial interface would be perfectly fine int timerfd(...); // Open ... int eventfd(...); // [1] Will work *even* with standard POSIX select/poll. 95% or more of the software does not have scalability issues, and select/poll are more portable and easy to use for simple stuff. On top of that, as I already said, they are *confined* interfaces that could be more easily adopted by other Unixes (if they are 100-200 lines on Linux, don't expect them to be a lot more on other Unixes) [2]. We *already* have the infrastructure inside Linux to deliver events (f_op-poll subsystem), how about we use that instead of just-another way? [3] Man you're so full of shit, your eyes are brown. NOBODY cares about select/poll or that the interfaces are going to be adopted by other Unixes. This issue has already been solved by then YEARS ago. What I want (and a ton of other users) is a SIMPLE and generic way to receive events from _MULTIPLE_multiple sources. I don't care about kernel-level portability, easiness or whatever, the linux kernel developers are good at not knowing what their users want. As for why common abstractions like file are a good thing, think about why having /dev/null is cleaner that having a special plug DEVNULL_FD fd value to be plugged everywhere, This is a stupid comparaison. By your logic we should also have /dev/stdin, /dev/stdout and /dev/stderr. or why I can use find/grep/cat/echo/... to look/edit at my configuration inside /proc, instead of using a frigging registry editor. Yet another stupid comparaison, /proc is a MESS! Almost as worse as the registry. Linux now has three pieces of crap for configuration/information: /proc, sysfs and sysctl. Nobody knows exactly what should go into each one of those. Crap design at it's best. But here the list could be almost endless. And please don't start the, they don't scale or they need heavy file binding tossfeast. They scale as well as the interface that will receive them (poll, select, epoll). Heavy file binding what? 100 or so bytes for the struct file? How many signal/timer fd are you gonna have? Like 100K? Really moot argument when opposed to the benefit of being compatible with existing POSIX interfaces and being more Unix friendly. So why the HELL don't we have those yet? Why haven't you designed epoll with those in mind? Why don't you back your claims with patches? (I'm not a kernel developer.) As for the AIO stuff, if threadlets/syslets will prove effective, you can host an epoll_wait over a syslet/threadlet. Or, if the 3 lines of userspace code needed to do that, fall inside your definition of kludge, we can even find a way to bridge the two. I don't care about threadlets in this context, I just want to wait for EVENTS from MULTIPLE sources WITHOUT mixing signals and other crap. Your arrogance is amusing, stop pushing narrow-minded beliefs down the throats of all Linux users. Kqueue, event ports, WaitForMultipleObjects, epoll with multiple sources. That's what users want, not yet another syscall/whatever hack. Now, how about we focus on the topic of this thread? [1] This could be an idea. People already uses pipes for this, but pipes has some memory overhead inside the kernel (plus use two fds) that could, if really felt necessary, be avoided. Yet another hack!! 64kiB of space just to push some user events around. Great idea! [2] This is how those kind of interfaces should be designed. Modular, re-usable, file-based interfaces, whose acceptance is not linked into slurping-in a whole new interface with tenths of sub, interface-only, objects. And from this POV, epoll is the friendlier. Who said I want yet another interface? I just fucking want to receive events from MULTIPLE sources through epoll. With or without a fd! My anger and frustration is that we can get past this SIMPLE need! [3] Notice the similarity between threadlets/syslets and epoll? They enable pretty darn good scalability, with *existing* infrastructure, and w
