sin()/cos()/tan() for kernel code? '_ 'a
Hello all, I am writing a mouse device driver for my Wacom tablet (Intuos 2 9x12). The tablet comes with a mouse and I managed to get valid coordinate data from the device. However, unlike usual mice, the coordinate system is tied not to the orientation of the mouse itself, but to the tablet, which acts much like a mouse pad. So, for example, if I rotate the mouse 30 degrees to the left and move it left and right, the mouse cursor would move not horizontally, but to 2- or 8-o'clock. Fortunately the mouse also provides orientation data along with coordinate data, so the correct cursor movement could be calculated from it. The problem: The calculation needs trigonometry, but there seems to be no math library support in the kernel (I ran grep -w cos on the -CURRENT source tree, which turned nothing up). Does anyone have an idea on how to do this? Cheers, Eugene ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portupgrade and dependencies
Unfortunately, the semantics of -r and -R options of pkg_info is the opposite of the semantics used by pkgtools (such as portupgrade/portinstall, pkg_glob and so on). Eugene Marek Denis wrote: On Tue, Dec 12, 2006 at 05:55:40PM -0500, Dino Michailidis wrote: portupgrade -r will also upgrade packages that depend on the port you are upgrading. It seems that this is not what you want. portupgrade -R will also upgrade packages required by the port you are upgrading - I believe this *is* what you want. Well, I don't get it. When I type: pkg_info -R libiconv-1.9.2_1 it shows many of the packages (ettercap too) so it is required by ettercap to work properly, yes? And when I type pkg_info -r ettercap it shows libiconv as a dependant, it mean a package which is required to work ettercap properly, yes? And that I have always thought -r option with portupgrade was all right for me. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
dump(8) performance
While watching the output of iostat -dxz -w10 -n100 to monitor the progress/performance of a dump(8) process straight to a tape, I found out something interesting and disappointing at the same time: The disk read throughput was exactly twice as high as the tape write throughput, throughout the entire dump phases 4 and 5, i.e. dumping actual inodes. Disappointing, because the tape drive utilization (%busy) was lingering around 35%-50% for most of the time; I didn't expect the disk would be the bottleneck. :p I want to believe that this indicates a bug in dump(8) which causes each disk block to be read twice, but being no UFS expert in any sense, I wonder: Could this behavior be by design, and would there be any room for improvement? Puzzled, Eugene ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump(8) performance
Dan Nelson wrote: Are you using the -C option to dump? I would expact that to help more in the dumping directories step, but it might help later phases too. Yep, -C32. Eugene ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
cpu_idle_hlt (Re: Confused about HyperThreading and Performance)
John Baldwin wrote: Also, as someone else mentioned, setting 'machdep.cpu_idle_hlt=1' can be useful on some HTT systems. However, p4's have a problem with their interrupt routing that can leave the second CPU halted for a long time if you do that. I have a few quick questions... Searched on Google but couldn't get satisfactory answers: 1. Without cpu_idle_hlt, is the problem that the idle spin loop one logical CPU executes would eat up CPU time and prevent the other logical CPU from running? 2. If so, would it explain the unusually high percentage of system time and unusually low percentage of user time (shown on systat -vm 1) when processes should be mostly doing CPU work and some heavy disk I/O at the same time? 3. Is cpu_idle_hlt also potentially unsafe on P4 Xeon-based SMP systems? Thanks, Eugene P.S. It'd be greatly appreciated if someone could point to an in-depth discussion about Hyperthreading and cpu_idle_hlt... *yells at his poor Googling skill XD* ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
pam_opieaccess.so and opiepasswd -d
Greetings, pam_opieaccess.so is documented to allow cleartext password (by returning PAM_SUCCESS) when OPIE is disabled for the user. However, on both -current and 4-stable, pam_opieaccess.so checks whether OPIE is enabled only by checking the existence of the user's record from /etc/opiekeys. Since a valid /etc/opiekeys record can also indicate that the OPIE access is disabled (i.e. one runs opiepasswd -d to set the value field to `'), I guess the module should check this as well. Currently this check is not performed, so when one has pam_opie.so plus pam_opieaccess.so combination, users with explicitly disabled OPIE record and a cleartext password won't be able to log in even when /etc/opieaccess allows cleartext password logins. Is the current behavior an intended feature, or should it be fixed (the patch would be trivial)? Eugene ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB Memorybird quirks
There is hardly a performance issue about 10-byte READ, considering the size of a whole transaction (command + transfer) is at least as large as a disk sector (512 bytes on most modern drives); a four-byte difference is almost nothing here. IMHO the best way is to `try a 10-byte READ first, and if it fails then fallback to a 6-byte READ.' Eugene On Fri, Feb 08, 2002 at 10:31:08AM -0800, Terry Lambert wrote: Gérard Roudier wrote: A couple of READ/WRITE 6 byte commands are still mandatory for SCSI block devices in order to accomodate softwares as boot software for example that may not be upgradable on systems still in use. Not a real problem, since if the device doesn't support the 5 byte commands, it's not booting with the legacy system software anyway, since you can't boot legacy stuff on it. Softwares that are maintained should no longer use 6 byte commands, but use the 10 byte commands replacement (for years...). This I don't understand. FreeBSD appears to have a preference for the 6 byte commands in the drivers, which are only used after boot. Further, it makes sense that you'd prefer 6 byte if you could, since it makes your commands 60% smaller, which should make them faster. So, unless we want to accomodate applications that still may send 6 byte commands through passthrough driver, no translator should be needed. Just make class drivers use 10 byte commands instead. There has to be a reason that FreeBSD has a preference for 6 bytes in the CAM code... ?!? OTOH, using 6 byte READ/WRITE commands is very restrictive if we ever want to implemement kind of trustable disk write caching support since they do not allow to selectively force media access (this is achieved by the FUA bit in = 10 byte READ/WRITE command). As a result, no device should be quirked nowadays as failing READ/WRITE 6 byte commands. Just maintained softwares should get rid of those commands asap. It sounds like devices that only support 6 byte commands are the ones that need quirked? In other words, you're just reversing the default and the fallback positions. I think auto-detecting the quirk is still a good bet, even in the 6 byte only case, just as it would have been in the 10 byte only case. Thanks for the info on what's supposed to be done going forward, though. If there's no performance issue with 10 byte commands, inverting the default and the quirk handling in the failure case seems to be the right thing to do. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: USB Memorybird quirks
This is a common problem of most umass devices that implements BBB protocol, and arises from the fact that those devices don't understand the 6-byte SCSI READ command. You can add a quirk entry to src/sys/cam/scsi_da.c (refer to quirk entries that have DA_Q_NO_6_BYTE). IIRC this problem is being addressed at a more fundamental level on -current, by adding a 6-byte-to-10-byte READ command translator somewhere in the abstraction layer. Eugene On Thu, Feb 07, 2002 at 09:46:28PM +0100, Oliver Fromme wrote: Hi, I've got a small problem with a nice little thing called USB Memorybird (Fujitsu-Siemens) ... It is bascially a 64 MB Flash chip in a small plastic pen that you can carry with your keys. It doesn't need any battery and you can plug it directly into a USB socket. Very neat. Works without any drivers on WinME and Win2k, so I assume it should be some standard USB mass storage device. FreeBSD 4.5 recognizes it out of the box and attaches it as a SCSI disk, but I cannot access it. This is what happens: From the boot log: uhci0: VIA 83C572 USB controller port 0xd400-0xd41f irq 10 at device 7.2 on pci0 usb0: VIA 83C572 USB controller on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered This appears when I connect the Memorybird: umass0: Fujitsu Memorybird, rev 1.00/1.00, addr 2 da2 at umass-sim0 bus 0 target 0 lun 0 da2: Fujitsu Memorybird 1.04 Removable Direct Access SCSI-0 device da2: 650KB/s transfers da2: 62MB (128000 512 byte sectors: 64H 32S/T 62C) This is the output from usbdevs -v (note that there is a ~10 seconds delay!): Controller /dev/usb0: addr 1: self powered, config 1, UHCI root hub(0x), VIA(0x), rev 0x0100 port 1 powered ~10 seconds delay port 2 addr 2: power 100 mA, config 1, product 0x0100(0x0100), vendor 0x0d7d(0x0d7d), rev 0x0100 When I type fdisk da2, it hangs for a while, then prints: fdisk: can't open device /dev/da2 fdisk: cannot open disk /dev/da2: Input/output error At the same time, the kernel logs this: Feb 7 20:00:31 lurza /kernel: umass0: BBB reset failed, TIMEOUT Feb 7 20:00:36 lurza /kernel: umass0: BBB bulk-in clear stall failed, TIMEOUT Feb 7 20:00:41 lurza /kernel: umass0: BBB bulk-out clear stall failed, TIMEOUT Feb 7 20:00:51 lurza /kernel: umass0: BBB reset failed, TIMEOUT Feb 7 20:00:56 lurza /kernel: umass0: BBB bulk-in clear stall failed, TIMEOUT Feb 7 20:01:01 lurza /kernel: umass0: BBB bulk-out clear stall failed, TIMEOUT The same happens when I try to dd some block from the device to /dev/null. During my experiments I also got these messages (I don't know if they're important): Feb 7 19:54:46 lurza /kernel: da2: reading primary partition table: error reading fsbn 0 Feb 7 19:54:56 lurza /kernel: umass0: BBB reset failed, TIMEOUT Feb 7 19:55:01 lurza /kernel: umass0: BBB bulk-in clear stall failed, TIMEOUT Feb 7 19:55:06 lurza /kernel: umass0: BBB bulk-out clear stall failed, TIMEOUT Feb 7 19:55:06 lurza /kernel: (da2:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi status == 0x0 Is there a chance to get this to run? Clearly the umass driver recognizes it and attaches it as a SCSI disk, so I assume that it can't be _that_ hard to convince it to work with FreeBSD. :) Are there any quirks that I should try? I'm not extremely familiar with that kind of stuff, but I'm willing to experiment. Thanks in advance for any help! I would _really_ love to get this thing working. Regards Oliver BTW: More information on the Memorybird: http://www.fujitsu-siemens.com/rl/peripherals/homeperipherals/memorybird.html -- Oliver Fromme, secnetix GmbH Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. All that we see or seem is just a dream within a dream (E. A. Poe) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hardware in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: USB Memorybird quirks
On Thu, Feb 07, 2002 at 03:52:26PM -0800, Terry Lambert wrote: Eugene M. Kim wrote: This is a common problem of most umass devices that implements BBB protocol, and arises from the fact that those devices don't understand the 6-byte SCSI READ command. You can add a quirk entry to src/sys/cam/scsi_da.c (refer to quirk entries that have DA_Q_NO_6_BYTE). IIRC this problem is being addressed at a more fundamental level on -current, by adding a 6-byte-to-10-byte READ command translator somewhere in the abstraction layer. Could this be auto-quirked? It seems to me that you should be able to add the quirk flag to the device instance after the first failure... Unfortunately, I don't have one of these toys, so he'll have to do the code himself. 8-). The USB development team seems to have something similar to your idea in their mind; see the comment for rev 1.47 of: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/usb/umass.c?f=uonly_with_tag=MAINlogsort=date It mentions about `da(4) becoming more intelligent about this.' Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
contigmalloc + contigfree = memory leak?
Greetings,
QUESTION:
Does contigfree() really free up memory allocated using contigmalloc()?
BACKGROUND:
I've been trying to make up a kmod that allocates/deallocates memory in
a specific physical address range. Mike Smith suggested using busdma
functions to do the job, so I followed it.
After allocating and deallocating memory several times, it seemed that
bus_dmamem_free() was not freeing the memory properly. I looked at
busdma_machdep.c where bus_dmamem_free() was defined, and found:
void
bus_dmamem_free(bus_dma_tag_t dmat, void *vaddr, bus_dmamap_t map)
{
/*
* dmamem does not need to be bounced, so the map should be
* NULL
*/
if (map != NULL)
panic(bus_dmamem_free: Invalid map freed\n);
/* XXX There is no contigfree and free doesn't work */
if ((dmat-maxsize = PAGE_SIZE) dmat-lowaddr = ptoa(Maxmem))
free(vaddr, M_DEVBUF);
}
However, there *is* contigfree() and a related patch was applied on
-current around August, so I did the same thing (adding an else clause
to call contigfree(vaddr, dmat-maxsize, M_DEVBUF)).
It didn't solve the memory leak problem either, so I'm stuck here...
Could anyone shed a light on this?
Regards,
Eugene
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: contigmalloc + contigfree = memory leak?
Oops, I'm sorry for the self-reply. Just found a highly helpful thread
posted from 11th (`contigfree, free what?'), so please disregard my
message.
/me bonks his head against a wall that says `mea culpa'
Thanks,
Eugene
On Tue, Oct 16, 2001 at 02:42:17PM +0900, Eugene M. Kim wrote:
Greetings,
QUESTION:
Does contigfree() really free up memory allocated using contigmalloc()?
BACKGROUND:
I've been trying to make up a kmod that allocates/deallocates memory in
a specific physical address range. Mike Smith suggested using busdma
functions to do the job, so I followed it.
After allocating and deallocating memory several times, it seemed that
bus_dmamem_free() was not freeing the memory properly. I looked at
busdma_machdep.c where bus_dmamem_free() was defined, and found:
void
bus_dmamem_free(bus_dma_tag_t dmat, void *vaddr, bus_dmamap_t map)
{
/*
* dmamem does not need to be bounced, so the map should be
* NULL
*/
if (map != NULL)
panic(bus_dmamem_free: Invalid map freed\n);
/* XXX There is no contigfree and free doesn't work */
if ((dmat-maxsize = PAGE_SIZE) dmat-lowaddr = ptoa(Maxmem))
free(vaddr, M_DEVBUF);
}
However, there *is* contigfree() and a related patch was applied on
-current around August, so I did the same thing (adding an else clause
to call contigfree(vaddr, dmat-maxsize, M_DEVBUF)).
It didn't solve the memory leak problem either, so I'm stuck here...
Could anyone shed a light on this?
Regards,
Eugene
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
VM question (I hate Intel 810/815 chipsets...)
What would be the best way to allocate: 1) a VM page whose physical address falls within a certain boundary, and 2) a VM object whose pages are contiguous in physical address space? Background: The !@*%^*!#^%*!#^$!@ Intel 810/815 graphics controller requires its instruction and hardware cursor buffers to reside within first 32MB and 512MB of *physical* memory space respectively. :( :( ;( The XFree86 driver assumes the Linux memory model (virtual addr == physical addr), so it runs on Linux, but not always on FreeBSD. Cheers, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: VM question (I hate Intel 810/815 chipsets...)
Thank you for the reply. I also found contigmalloc() shortly after I posted the original question (what an embarrassment ;-p), then met another restriction: Because these memory regions are to be accessed by a userland process (X server), they have to be somehow mapped into the user space. So far it seems I would have to do something similar to vm_mmap(), but I'm not sure if this is a right direction. Do you have any suggestions? Cheers, Eugene On Tue, Oct 09, 2001 at 07:37:41PM -0500, Jonathan Lemon wrote: In article local.mail.freebsd-hackers/[EMAIL PROTECTED] you write: What would be the best way to allocate: 1) a VM page whose physical address falls within a certain boundary, and 2) a VM object whose pages are contiguous in physical address space? Background: The !@*%^*!#^%*!#^$!@ Intel 810/815 graphics controller requires its instruction and hardware cursor buffers to reside within first 32MB and 512MB of *physical* memory space respectively. :( :( ;( The XFree86 driver assumes the Linux memory model (virtual addr == physical addr), so it runs on Linux, but not always on FreeBSD. You probably want contigmalloc(), which allocates a range of memory which is physically contiguous. (assuming this is a in-kernel driver) void * contigmalloc( unsigned long size, /* should be size_t here and for malloc() */ struct malloc_type *type, int flags, unsigned long low, unsigned long high, unsigned long alignment, unsigned long boundary) -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: IDE CDRW
One more similar question: Does/will FreeBSD support ATAPI CD-R(W) drives in disk-at-once mode, perhaps using burncd(1)? I wanted to burn some audio CDs in that manner but burncd on 4-stable didn't support DAO writing. Thank you, Eugene -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Kris Kennaway Sent: Wednesday, January 24, 2001 6:53 PM To: Felix-Antoine Paradis Cc: [EMAIL PROTECTED] Subject: Re: IDE CDRW On Wed, Jan 24, 2001 at 05:04:23PM -0500, Felix-Antoine Paradis wrote: Just a simple question, FreeBSD doesn't support/emulate any IDE CDRW? It supports them just fine.. Perhaps your question was really "does FreeBSD emulate a SCSI interface to ATAPI drives?", in which case the answer is "no". They are still fully functional however. Kris -- NOTE: To fetch an updated copy of my GPG key which has not expired, finger [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Unicode on FreeBSD
of people are willing to throw in their voice. Regards, Eugene -- Eugene M. Kim [EMAIL PROTECTED] "Is your music unpopular? Make it popular; make music which people like, or make people who like your music." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Unicode on FreeBSD
On Mon, 3 Apr 2000, Alex Belits wrote: | On Mon, 3 Apr 2000, G. Adam Stanislav wrote: | |Really the question is much more basic -- who benefits from having | Unicode (or Unicode in the form of UTF-8) support. It isn't me for sure | | Everyone who works with multilingual documents. | | I feel perfectly fine with "multilingual" documents that contain English | and Russian text without Unicode. Please, try thinking wider. Ever thought a mixture of Russian, Hebrew, Korean and English? AFAIK no CCS other than Unicode currently can handle this. | | Everyone who wants to | follow a single international standard as opposed to a slew of mutually | exclusive local standards. Anyone who thinks globally. | | "Globally" in this case means following self-proclaimed unificators from | Unicode Consortium. | | Anyone who has anything to do with the Internet must deal with UTF-8: | "Protocols MUST be able to use the UTF-8 charset, which consists of the ISO | 10646 coded character set combined with the UTF-8 character encoding | scheme, as defined in [10646] Annex R (published in Amendment 2), for all | text." RFC 2277 | | This is not approved by ANYONE but a bunch of "unificators". It never | was widely discussed, and affected people never had a chance to give any | input. This is the same kind of "standard documents" that ITU issues by | dozens. True, personally I don't like the way Unicode Consortium operates either; I'd prefer a more open system such as IETF. However, it seems an error to brand Unicode as a bad-motivated idea just because the operating body is less ideal. And given that RFC 2277 is just a BCP (Best Current Practice) but not a `standard' document, it doesn't have to be approved by anyone either. If you don't feel right about it, why don't you send a short e-mail message to its author? | | -- I am Russian. | | So? | | So I don't want UTF-8 to be forced on me. Charset definitions in MIME | headers exist for a reason. If we want to make something usable we can | create a format that can encapsulate existing charsets instead of banning | them altogether and replacing with "unified" stuff where cut(1) and | dd(1) can produce the output that will be declared "illegal" to be | processed as text because it can not be a valid UTF-8 sequence. Nobody is banning anything. Please be reminded that RFC 2277 only mandates the support for UTF-8. One can still go ahead and use US-ASCII, EUC-KR, or whatever you want so far as the protocol supports character set designation such as MIME. And again, RFC 2277 is a BCP. Unlike standards, BCPs has no enforcing power at all. | | One of the most basic strengths of Unix is the ease with which text can | be manipulated, and how "non-text" data can be processed using the same | tools without any complex "this is text and this is not" | application-specific procedures. UTF-8 turns "text" into something that | gives us a dilemma -- to redesign everything to treat "text" as the stream | of UTF-8 encoded Unicode (and make it impossible to combine text and | "non-text" without a lot of pain), or to leave tools as they are and deal | with "invalid" output from perfectly valid operations. In | Windows/Office/... that lives and feeds on complex and unparceable formats | this problem couldn't appear or even thought of -- "text" doesn't exist as | text at all, and the less stuff will look as something that can be usable | outside of strict "object" environment, the better (they now don't even | encode it in UTF-8, and use bare 16-bit Unicode). In Unixlike system it's | a violation of some very basic rules. Yes, it is true that the entire UN*X world is so deeply rooted in single byte-oriented world and it's hard to come up with a reasonable migration path to the multibyte world. But that doesn't justify the byte-oriented system. It has all too many limitations (which you might not realize until you had to mix all different languages in one document; I did :-p), and there has to be an alternative. I'm not saying that the entire UN*X world should migrate to the Unicode world in months. We all know that is just impossible. Eugene -- Eugene M. Kim [EMAIL PROTECTED] "Is your music unpopular? Make it popular; make music which people like, or make people who like your music." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Unicode on FreeBSD
On 2 Apr 2000, Christian Weisgerber wrote: | I also think the creating of a freebsd-i18n list is long overdue. | I18N issues are largely lost among the traffic on -hackers and | -questions, and it has become something of a specialty area since | most people appear to be served well by the existing non-solutions. I second this idea. Regards, Eugene -- Eugene M. Kim [EMAIL PROTECTED] "Is your music unpopular? Make it popular; make music which people like, or make people who like your music." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Unicode on FreeBSD
On Mon, 3 Apr 2000, Nik Clayton wrote: | On Mon, Apr 03, 2000 at 11:37:22AM -0700, Eugene M. Kim wrote: | On 2 Apr 2000, Christian Weisgerber wrote: | | I also think the creating of a freebsd-i18n list is long overdue. | | I18N issues are largely lost among the traffic on -hackers and | | -questions, and it has become something of a specialty area since | | most people appear to be served well by the existing non-solutions. | | I second this idea. | | I do, sort of. I think (BICBW) there's a big overlap between carrying | out i18n work on the code and message catalogs, and carrying out i18n | work on the documentation. There is already a freebsd-translators | (@ngo.org.uk) mailing list with very little traffic that could be | migrated to freebsd.org and used for both. Yes. In fact I prudently predict that if we launched an i18n mailing list we would soon get into the same set of problems every i18n project has (e.g. unification vs. localization). For this purpose, having a group of people already involved in i18n (regardless they are programmers or doc writers) migrated into the new list would be a great idea. -- Eugene M. Kim [EMAIL PROTECTED] "Is your music unpopular? Make it popular; make music which people like, or make people who like your music." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Session leader releasing the ctty
Hello, I'm having a trouble programming a special login shell, and would like to hear any opinions on this. I want this shell (which automatically becomes a session leader) to release its ctty but remain unterminated (the ctty must be taken by its child). However, there seems to be no easy way to do this; termios(4) says one must call setsid() to release its ctty, but setsid(2) says the call will fail if the caller is already a session leader. Would there be any other way for a session leader to release its ctty without terminating itself? TIA. Cheers, Eugene Kim PS. I'm now using a workaround that the shell will forward the SIGHUP that it received because it's a session leader, but this isn't a clean way. :-p -- Eugene M. Kim NTT Multimedia Communications Laboratories Software Developer 250 Cambridge Avenue, Suite 205 +1 650 833 3630 (Voice) Palo Alto, CA 94040, USA +1 650 833 3633 (Fax) mailto:g...@nttmcl.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
