Re: fdescfs functional in 6.1?
I guess I just expected it to print all character device entries for the file descriptors open by my process. Kind of like the old /dev/fd/1 /dev/fd/2 directories used to be under MAKEDEV... On Fri, Jul 28, 2006 at 11:18:48PM -0500, Dan Nelson wrote: In the last episode (Jul 28), Jaye Mathisen said: devfs is mounted, fdesc is unmounted: s2# ls -l /dev/fd total 0 crw-rw-rw- 1 root wheel 250, 0 Jul 25 03:25 0 crw-rw-rw- 1 root wheel 250, 1 Jul 25 03:28 1 crw-rw-rw- 1 root wheel 250, 2 Jul 25 03:27 2 Looks just like I think it should. Then: s2# mount -t fdescfs fdescfs /dev/fd s2# ls -l /dev/fd total 16 crw--w 1 root tty 5, 1 Jul 28 18:01 0 crw--w 1 root tty 5, 1 Jul 28 18:01 1 crw--w 1 root tty 5, 1 Jul 28 18:01 2 d-w--- 1 mailnull mailnull 512 Jul 23 00:01 3 d- 1 root wheel 512 Jul 25 03:25 4 s2# umount /dev/fd This thing is all over the map.. permissions changed, a *directory* for fd's 3 and 4? What do you expect ls to open to print a *directory* listing? :) fd's 0, 1, and 2 are /dev/tty, and the permissions look fine. fd 3 is your current directory (so I guess you're in some smtp-related directory?), and fd 4 is the directory on the commandline (/dev/fd). -- Dan Nelson [EMAIL PROTECTED] !DSPAM:44caf09f196113296012617! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: disklabel differences FreeBSD, DragonFly
On Fri, Jul 28, 2006 at 03:36:27PM -0700, Matthew Dillon wrote: :On Thu, Jul 27, 2006 at 02:21:59PM +0200, Joerg Sonnenberger wrote: : On Thu, Jul 27, 2006 at 08:39:37AM +0200, Andreas Klemm wrote: : :Hmm, for the sake of compatibility, wouldn't it have been an option, :to add this extra bit to the end of the struct ? : Andreas /// The thing to note here is that FreeBSD had to make room for the UFS1+UFS2 boot code, so it moved the boot code back to the point where it abuts the 8-partition-sized disklabel. So at least insofar as FreeBSD goes, the partition table cannot be expanded to 16 partitions with UFS1+UFS2 boot code. I'm guessing that it *could* be expanded to 16 partitions with UFS1 only or UFS2 only boot code (assuming the boot code were relocated back to where it was originally in FreeBSD-4/5 times, before UFS2 came along). With regards to simply recognizing a DragonFly partition... yes, that would be easy to do. Since FreeBSD is now devfs-based, the bit we had to steal to support 16 partitions in /dev isn't an issue. Couldn't all BSDs restructure the disklabel in -current so that we would have the same base for the next major release ? Then its only a question of drivers to suppot UFS2 or not. But then compatibility would be there for some time ... Incompatible to UFS's like from Sun I think we are already, so we don't have to honour them. Remember a current thread in german BSD group where somebody complained about FreeBSD - mounting a Sun filesystem r/w - destroyed the filesystem. Luckily he could recover using fsck -b 32. Andreas /// -- Andreas Klemm - Powered by FreeBSD 6 Need a magic printfilter today ? - http://www.apsfilter.org/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: disklabel differences FreeBSD, DragonFly
* Matthew Dillon ([EMAIL PROTECTED]) wrote: felt that 8 partitions is restrictive. My main home server has 10 and the main DragonFly box has 11. There is another solution for FreeBSD folks, however. You *DO* have four slices to play with. You can put a disklabel with 8 partitions in it on each one (for 32 total). It isn't as convenient, but it does work. About `lack' of partitions - don't forget that labels can be nested. Just do `bsdlabel -w /dev/ad0s1e` - you'll get /dev/ad0s1ea. -- Best regards, Dmitry mailto:[EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
i386 page fault clobbers error code in trap frame
I'm refering to the following two lines in sys/i386/i386/trap.c /* kludge to pass faulting virtual address to sendsig */ frame-tf_err = eva; Isn't there some other way to do this? Wouldn't the address still be available in %cr2 inside sendsig? Or could there have been other page faults by then? The reason I'm asking this is that Wine wants to know the error code in case of a page fault (the No eXec bit (AMD) and the read/write bit specifically). pgpeKHupw8FpA.pgp Description: PGP signature
Re: i386 page fault clobbers error code in trap frame
Looking at siginfo it isn't clear that there is a right way to
provide SIGSEGV, eva, and the error code.
_fault._trapno should contain the machine's error code and si_signo
should contain SIGSEGV, and si_addr contains the faulting pc. Maybe
one could abuse si_code to contain eva. Sorry for asking a question
that has already been answered but where is eva being put currently?
typedef struct __siginfo {
int si_signo; /* signal number */
int si_errno; /* errno association */
/*
* Cause of signal, one of the SI_ macros or signal-specific
* values, i.e. one of the FPE_... values for SIGFPE. This
* value is equivalent to the second argument to an old-style
* FreeBSD signal handler.
*/
int si_code;/* signal code */
__pid_t si_pid; /* sending process */
__uid_t si_uid; /* sender's ruid */
int si_status; /* exit value */
void*si_addr; /* faulting instruction */
union sigval si_value; /* signal value */
union {
struct {
int _trapno;/* machine specific trap code */
} _fault;
/* */
On 7/29/06, Tijl Coosemans [EMAIL PROTECTED] wrote:
I'm refering to the following two lines in sys/i386/i386/trap.c
/* kludge to pass faulting virtual address to sendsig */
frame-tf_err = eva;
Isn't there some other way to do this? Wouldn't the address still be
available in %cr2 inside sendsig? Or could there have been other page
faults by then?
The reason I'm asking this is that Wine wants to know the error code in
case of a page fault (the No eXec bit (AMD) and the read/write bit
specifically).
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] adding two new options to 'cp'
Eric Anderson wrote: So, you can mimic an entire tree with something like: cp -al /from/ /to/ pax -rwl -pe /from /to is almost what you want. (It requires that /to exist first, though.) If you want to match the 'cp' semantics when /to does not exist, you can use pax's rewrite option: pax -rwl -pe -s|/from|/to| /from / As a bonus, this works on any machine that meets POSIX, unlike every other option that's been mentioned in this thread (tar and cpio were both dropped from the POSIX standard a decade ago). Tim ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fdescfs functional in 6.1?
In the last episode (Jul 28), Jaye Mathisen said: On Fri, Jul 28, 2006 at 11:18:48PM -0500, Dan Nelson wrote: In the last episode (Jul 28), Jaye Mathisen said: s2# mount -t fdescfs fdescfs /dev/fd s2# ls -l /dev/fd total 16 crw--w 1 root tty 5, 1 Jul 28 18:01 0 crw--w 1 root tty 5, 1 Jul 28 18:01 1 crw--w 1 root tty 5, 1 Jul 28 18:01 2 d-w--- 1 mailnull mailnull 512 Jul 23 00:01 3 d- 1 root wheel 512 Jul 25 03:25 4 s2# umount /dev/fd This thing is all over the map.. permissions changed, a *directory* for fd's 3 and 4? What do you expect ls to open to print a *directory* listing? :) fd's 0, 1, and 2 are /dev/tty, and the permissions look fine. fd 3 is your current directory (so I guess you're in some smtp-related directory?), and fd 4 is the directory on the commandline (/dev/fd). I guess I just expected it to print all character device entries for the file descriptors open by my process. fdescfs prints all file desriptors open by your process, and displays the correct info for each of them. Kind of like the old /dev/fd/1 /dev/fd/2 directories used to be under MAKEDEV... Before devfs, /dev/fd was populated with dummy entries from 0 to 63 and running ls on the directory had no correspondence with what your process actually had open. -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fdescfs functional in 6.1?
On Fri, Jul 28, 2006 at 11:16:53PM -0700, Jaye Mathisen wrote: I guess I just expected it to print all character device entries for the file descriptors open by my process. It did-- well it printed all the file descriptors open by your process, which in this case was ls. 0, 1, and 2 are stdin, stdout, and stderr (respectfully) and they point to the device you logged into. Try doing ls -la /dev/fd | less and I'll bet 1 will be a pipe? This seems like the correct operation; I'm not sure I understand what you expected and why that's different than what you've observed. Kind of like the old /dev/fd/1 /dev/fd/2 directories used to be under MAKEDEV... How is that the same? MAKEDEV was in the day before devfs, so the device entries needed to be created by the underlying filesystem. In devfs, things are only present if they represent an active device. -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
