vised the patch slightly:
http://people.freebsd.org/~jh/patches/devfs-rule-fullpath.3.diff
There is no functional change. I intend to commit the patch soon.
--
Jaakko
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/lis
On 2013-03-28, Andriy Gapon wrote:
> > Would like to ask for opinions on this topic...
> > Please read this PR for context:
> > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/122838
> > Especially Jaakko's insightful description of the problem.
>
> So I would like to commit the following patch so
d like to commit the following patch sooner rather than later:
http://people.freebsd.org/~avg/devfs_rule.diff
The only difference from the Jaakko's patch in the PR is FNM_PATHNAME.
Please review and test.
Especially if you rely on any non-trivial devfs rules.
Th
gt; Original Message
> Message-ID: <5150b598.7050...@freebsd.org>
> Date: Mon, 25 Mar 2013 22:37:44 +0200
> From: Andriy Gapon
> Subject: Re: kern/122838: [devfs] devfs doesn't handle complex paths (like
> zvol/pool/vms) good
>
>
> Can't believe t
25 Mar 2013 22:37:44 +0200
From: Andriy Gapon
Subject: Re: kern/122838: [devfs] devfs doesn't handle complex paths (like
zvol/pool/vms) good
Can't believe that we are still where we were more than two years ago...
I think that we have to make this change even if it _might_ break s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 10/22/2010 11:47 AM, Kostik Belousov wrote:
| The LORs are believed to be harmless.
IMO the problem with that line of reasoning is that while any individual
LOR may be harmless there are so many harmless ones that it leads to
people either ignor
On Fri, Oct 22, 2010 at 2:47 PM, Kostik Belousov wrote:
> The LORs are believed to be harmless.
OK, I won't worry about it. I did check the list on
sources.zabbadoz.net and didn't see any for nfs & devfs or nfs &
syncer, so I just wanted t
On Fri, Oct 22, 2010 at 01:46:54PM -0400, Linda Messerschmidt wrote:
> When mounting a devfs filesystem on top of a directory in an NFS
> filesystem under 8.1-RELEASE-p1 r213075M, the following lock order
> reversal is reported:
>
> lock order reversal:
> 1st 0xc264bbdc nfs (n
When mounting a devfs filesystem on top of a directory in an NFS
filesystem under 8.1-RELEASE-p1 r213075M, the following lock order
reversal is reported:
lock order reversal:
1st 0xc264bbdc nfs (nfs) @ /usr/src/sys/kern/vfs_mount.c:1058
2nd 0xc264bce8 devfs (devfs) @ /usr/src/sys/kern
hen I unload
the driver when the kernel is built with INVARIANTS, I'll see a
panic in devfs_populate_loop(). This happens in 6-stable,
as well as 8-stable.
>From what I can see the clone has been freed, but it
remains on the devfs cdevp_list. Then the next time
devfs_populate_loop() is cal
cleanup(). When I unload
> >>the driver when the kernel is built with INVARIANTS, I'll see a
> >>panic in devfs_populate_loop(). This happens in 6-stable,
> >>as well as 8-stable.
> >>
> >>From what I can see the clone has been freed, but it
> >&g
a
panic in devfs_populate_loop(). This happens in 6-stable,
as well as 8-stable.
From what I can see the clone has been freed, but it
remains on the devfs cdevp_list. Then the next time
devfs_populate_loop() is called, it trips over the bad
entry (cdp->cdp_dirents points to 0xdeadc0dedeadc0de)
See appended
populate_loop(). This happens in 6-stable,
> as well as 8-stable.
>
> From what I can see the clone has been freed, but it
> remains on the devfs cdevp_list. Then the next time
> devfs_populate_loop() is called, it trips over the bad
> entry (cdp->cdp_dirents points to 0xde
clone has been freed, but it
remains on the devfs cdevp_list. Then the next time
devfs_populate_loop() is called, it trips over the bad
entry (cdp->cdp_dirents points to 0xdeadc0dedeadc0de)
See appended kgdb session.
If I trace the code path, it looks like clone_cleanup()
calls destroy
sn't happy with such a change?
>
> Have you done some locking there? Because my system crashes with such
> straightforward change, when g_dev_close() called after geom node being
> destroyed. Attached patch fixes that for me, but I have doubts that it
> is complete. There
called after geom node being
destroyed. Attached patch fixes that for me, but I have doubts that it
is complete. There is still seems to be a race with new I/O requests and
ioctl's, that are not protected by topology lock. At least if devfs code
doesn't handle it somehow.
--
Alexan
On Monday 01 February 2010 10:23:34 Pawel Jakub Dawidek wrote:
> On Sat, Jan 30, 2010 at 12:44:51PM +0100, Pawel Jakub Dawidek wrote:
> > Maybe I'll add how I understand what's going on:
> >
> > GEOM calls destroy_dev() while holding the topology lock.
> >
> > Destroy_dev() wants to destroy device,
On Sat, Jan 30, 2010 at 12:44:51PM +0100, Pawel Jakub Dawidek wrote:
> Maybe I'll add how I understand what's going on:
>
> GEOM calls destroy_dev() while holding the topology lock.
>
> Destroy_dev() wants to destroy device, but can't because there are
> threads that still have it open.
>
> The
Hi all,
* Kostik Belousov wrote:
> My exemplary case has been snp(4) before tty got rewritten, see r. 1.107
> of sys/dev/snp/snp.c. No calls to destroy_dev_sched() that I placed in
> the src/ a kept around, that is good because corresponding subsystems
> got serious rewrite.
The current TTY code
SATA hot-plug I've found quite repeatable deadlock
> >>> case. Problem observed when several SATA devices, opened via devfs,
> >>> disappear at exactly same time. In my case, at time of unplugging SATA
> >>> Port Multiplier with several disks beyond it. All I
served when several SATA devices, opened via devfs,
>>> disappear at exactly same time. In my case, at time of unplugging SATA
>>> Port Multiplier with several disks beyond it. All I have to do is to run
>>> several `dd if=/dev/adaX of=/dev/null bs=1m &` commands and unplug
hot-plug I've found quite repeatable deadlock
> > > case. Problem observed when several SATA devices, opened via devfs,
> > > disappear at exactly same time. In my case, at time of unplugging SATA
> > > Port Multiplier with several disks beyond it. All I have to do is to r
On Sat, Jan 30, 2010 at 12:27:49PM +0100, Pawel Jakub Dawidek wrote:
> On Sat, Jan 30, 2010 at 12:58:26AM +0200, Alexander Motin wrote:
> > Hi.
> >
> > Experimenting with SATA hot-plug I've found quite repeatable deadlock
> > case. Problem observed when severa
On Sat, Jan 30, 2010 at 12:58:26AM +0200, Alexander Motin wrote:
> Hi.
>
> Experimenting with SATA hot-plug I've found quite repeatable deadlock
> case. Problem observed when several SATA devices, opened via devfs,
> disappear at exactly same time. In my case, at time of un
Kostik Belousov wrote:
> On Sat, Jan 30, 2010 at 12:58:26AM +0200, Alexander Motin wrote:
>> Hi.
>>
>> Experimenting with SATA hot-plug I've found quite repeatable deadlock
>> case. Problem observed when several SATA devices, opened via devfs,
>> disappear at
On Sat, Jan 30, 2010 at 12:58:26AM +0200, Alexander Motin wrote:
> Hi.
>
> Experimenting with SATA hot-plug I've found quite repeatable deadlock
> case. Problem observed when several SATA devices, opened via devfs,
> disappear at exactly same time. In my case, at time of un
Hi.
Experimenting with SATA hot-plug I've found quite repeatable deadlock
case. Problem observed when several SATA devices, opened via devfs,
disappear at exactly same time. In my case, at time of unplugging SATA
Port Multiplier with several disks beyond it. All I have to do is to run
severa
ot;, hz / 10);
>>> }
>>>
>>> loop, add
>>>
>>> mtx_unlock(&devmtx);
>>> if (!cold)
>>> devctl_notify("DEVFS", dev->si_name, "DESTROY", NULL);
>>> mtx_lock(&devmtx);
>
roy_devl(), after the
> >
> > while (dev->si_threadcount != 0) {
> > /* Use unique dummy wait ident */
> > msleep(&csw, &devmtx, PRIBIO, "devdrn", hz / 10);
> > }
> >
> >loop, add
> >
> > mtx_u
que dummy wait ident */
msleep(&csw, &devmtx, PRIBIO, "devdrn", hz / 10);
}
loop, add
mtx_unlock(&devmtx);
if (!cold)
devctl_notify("DEVFS", dev->si_name, "DESTROY", NULL);
mtx_lock(&am
>gone. Typical holder of the reference is the devfs vnode. In the normal
> >usage, the vnode is present until both the device is destroyed _and_
> >devfs_populate_loop() run is performed. This function actually reclaim
> >the vnodes for destroyed devices, that causes last refere
devfs vnode. In the normal
usage, the vnode is present until both the device is destroyed _and_
devfs_populate_loop() run is performed. This function actually reclaim
the vnodes for destroyed devices, that causes last reference to cdev to
be dropped and memory freed.
The populate loop is called
on 12/05/2008 00:48 Kostik Belousov said the following:
No, we do not have a leak, but we have somewhat non-obvious behaviour.
The cdev structure is freed only after the last reference to cdev is
gone. Typical holder of the reference is the devfs vnode. In the normal
usage, the vnode is present
I missed or something even more obvious?
> I hope that we do not have any cdev leaks.
>
> I am testing the patch with RELENG_7 as of May 6.
No, we do not have a leak, but we have somewhat non-obvious behaviour.
The cdev structure is freed only after the last reference to cdev is
gone. Ty
@@ -99,6 +100,9 @@ dev_unlock_and_free(void)
mtx_unlock(&devmtx);
while ((cdp = TAILQ_FIRST(&cdp_free)) != NULL) {
+ if (!cold)
+ devctl_notify("DEVFS", cdp->cdp_c.si_name, "DESTROY",
NULL);
+
In message: <[EMAIL PROTECTED]>
: However it is possible that it did something wrong - at that time I had
: devctl calls in kern_conf.
I'd be inclined to say 'create' and 'destroy' for the events. ATTACH
and DETACH are typically reserved for device driver events, not for
device node events.
Warn
In message: <[EMAIL PROTECTED]>
Andriy Gapon <[EMAIL PROTECTED]> writes:
: on 23/04/2008 00:06 Jille said the following:
: > Andriy Gapon wrote:
: >> Maybe this is a crazy idea or maybe we already have something like this.
: >> Is it possible to get notificat
on 25/04/2008 17:36 Kostik Belousov said the following:
The malloc and free cannot be called while holding dev_mtx, this causes
the LORs. Please, look at the rev. 1.207, 1.210 of the kern/kern_conf.c
for the workarounds for the malloc issues. It seems that you may abuse the
dev_unlock_and_free()
On Fri, Apr 25, 2008 at 05:12:12PM +0300, Andriy Gapon wrote:
> on 25/04/2008 12:50 Kostik Belousov said the following:
> >Did you run this with WITNESS ?
> >
> >You put the whole devctl_notify() call under the dev_mtx. This includes
> >the malloc(), PROC_LOCK() and signalling, and some internal de
on 25/04/2008 12:50 Kostik Belousov said the following:
Did you run this with WITNESS ?
You put the whole devctl_notify() call under the dev_mtx. This includes
the malloc(), PROC_LOCK() and signalling, and some internal devctl_queue()
stuff. This is wrong.
Kostik,
I tried this patch only with
> http://www.icyb.net.ua/~avg/devd.log.gz
> Search for DEVFS for interesting lines.
>
> --
> Andriy Gapon
> diff --git a/sys/fs/devfs/devfs_devs.c b/sys/fs/devfs/devfs_devs.c
> index ca5c2de..3556799 100644
> --- a/sys/fs/devfs/devfs_devs.c
> +++ b/sys/fs/devfs/devfs
system is booted and devd
is running.
Here is a log of devd started with -dD flags in single-user mode, then I
attached and later detached an external hdd:
http://www.icyb.net.ua/~avg/devd.log.gz
Search for DEVFS for interesting lines.
--
Andriy Gapon
diff --git a/sys/fs/devfs/devfs_devs.c b/sys/fs
On Thursday 24 April 2008 04:05:10 am Andriy Gapon wrote:
> on 24/04/2008 01:39 Andriy Gapon said the following:
> > on 23/04/2008 22:49 John Baldwin said the following:
> >> Events have a subsystem associated with them, so devfs events would use
> >> their own subsystem
on 24/04/2008 01:39 Andriy Gapon said the following:
> on 23/04/2008 22:49 John Baldwin said the following:
>> Events have a subsystem associated with them, so devfs events would use
>> their
>> own subsystem type to avoid that sort of confusion.
>
> Thank you for
on 23/04/2008 22:49 John Baldwin said the following:
>
> Events have a subsystem associated with them, so devfs events would use their
> own subsystem type to avoid that sort of confusion.
Thank you for straightening me - for some reason I was thinking about
"+"/"-"
ssible to get notifications about changes in devfs - appearance
> >> and disappearance of devices (in devfs sense of the word)?
> >> devctl currently notifies about real (hardware) devices handled by
> >> device drivers and some notifications about hardware/driver events.
>
on 23/04/2008 16:55 John Baldwin said the following:
> On Tuesday 22 April 2008 03:54:17 pm Andriy Gapon wrote:
>> Maybe this is a crazy idea or maybe we already have something like this.
>> Is it possible to get notifications about changes in devfs - appearance
>> and disappe
On Tuesday 22 April 2008 03:54:17 pm Andriy Gapon wrote:
> Maybe this is a crazy idea or maybe we already have something like this.
> Is it possible to get notifications about changes in devfs - appearance
> and disappearance of devices (in devfs sense of the word)?
> devctl curren
on 23/04/2008 00:06 Jille said the following:
> Andriy Gapon wrote:
>> Maybe this is a crazy idea or maybe we already have something like this.
>> Is it possible to get notifications about changes in devfs - appearance
>> and disappearance of devices (in devfs sense of
Andriy Gapon wrote:
Maybe this is a crazy idea or maybe we already have something like this.
Is it possible to get notifications about changes in devfs - appearance
and disappearance of devices (in devfs sense of the word)?
devctl currently notifies about real (hardware) devices handled by
Maybe this is a crazy idea or maybe we already have something like this.
Is it possible to get notifications about changes in devfs - appearance
and disappearance of devices (in devfs sense of the word)?
devctl currently notifies about real (hardware) devices handled by
device drivers and some
Stef Walter wrote:
> After deleting a device in devfs, any symlink placed over it results in
> ENOENT.
>
> I'd like to fix this behavior. Or is there a reason for it that I'm not
> seeing?
Filed a bug report with a patch that solves the issue:
http://www.freebsd.org/c
After deleting a device in devfs, any symlink placed over it results in
ENOENT.
# cd /dev
# rm console
# touch /var/log/console
# ln -s /var/log/console console
# ls -l console
ls: console: No such file or directory
I'd like to fix this behavior. Or is there a reason for it tha
; waitchannels and debugging. I know there is someone working out issues
> in devfs code in 6.x, so this might also be interesting to him.
>
> I've been able to reproduce both in 6.1-RELEASE-p3 and 6-STABLE
> (snapshot from August 16th ~01:00 GMT) a deadlock in devfs code which
&g
While removing a tape device from an FC fabric, I got a nice panic. I
have screen captures posted here:
http://www.googlebit.com/freebsd/snapshots/devfs_panic/
This is 6-STABLE (amd64) as of about a week ago.
Sorry for the screen captures - that's all I had at the time. I do have
a vmcore s
s
finished, but unfortunately it gets frozen at random points,
preventing the system from launching new programs or saving to disk,
which suggested a kernel bug, as was later confirmed looking at the
waitchannels and debugging. I know there is someone working out issues
in devfs code in 6.x, so thi
On Tue, 3 Jan 2006, TSaplin Mikhail wrote:
Hi all i have a problem with devfs device hiding.
My system is FreeBSD 6.0 (i386 and amd64, compiled from last sunday source
(RELENG_6))
After mounting defs:
#mount -t devfs devfs /tmp/proba
first devfs command:
# devfs -m /tmp/proba rule add type
Hi all i have a problem with devfs device hiding.
My system is FreeBSD 6.0 (i386 and amd64, compiled from last sunday source
(RELENG_6))
After mounting defs:
#mount -t devfs devfs /tmp/proba
first devfs command:
# devfs -m /tmp/proba rule add type disk hide
devfs rule: ioctl DEVFSIO_RADD: Input
In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
org writes:
>Hi, as you know, we can create arbitaly file name on devfs.
>But for now, all file names on a devfs are encoded in ASCII.
>
>If we want to put Japanese file names in devfs, how should it
>be encoded? UTF-8 or som
Hi, as you know, we can create arbitaly file name on devfs.
But for now, all file names on a devfs are encoded in ASCII.
If we want to put Japanese file names in devfs, how should it
be encoded? UTF-8 or something convinient for the source encoding
sql: provider da1 activated.
May 12 10:41:07 bsd kernel: GEOM_MIRROR: Device sql: provider da0 activated.
May 12 10:41:07 bsd kernel: GEOM_MIRROR: Device sql: provider
mirror/sql launched.
May 12 10:41:14 bsd kernel: DEVFS Overflow table with 32768 entries allocated
Any help?
Tnx in advance.
--
Cris, mem
Hello,
I'm running a RELENG_5_2 box and I'm trying to use the devfs to change the
file permissions on
/dev/ttyd1. After perusing through the man page, I tried to change the
permissions by doing this
# ls -ol /dev/ttyd1
crw--- 1 root wheel - 28, 1 Jan 15 20:47 /dev/ttyd1
#
quite rudimentary. since I didn't give him any feedback
about "the next version I planned" (short of time and I focused on
jailctl utility), he did the commit.
Scot W. Hetzel made very impressive enhancements to it (including devfs
handling):
http://lists.freebsd.org/pipermail/freebs
On Thu, Jul 03, 2003 at 10:07:57PM -0400, Robert Watson wrote:
>
> On Thu, 3 Jul 2003, Joshua Oreman wrote:
>
> > On Thu, Jul 03, 2003 at 04:00:46AM -0700 or thereabouts, Josh Brooks wrote:
> > >
> > > I have been researching the various of ways people add devfs
On Thu, 3 Jul 2003, Joshua Oreman wrote:
> On Thu, Jul 03, 2003 at 04:00:46AM -0700 or thereabouts, Josh Brooks wrote:
> >
> > I have been researching the various of ways people add devfs to a jail to
> > give the jail certian /dev devices necessary to function ...
>
&g
Josh Brooks wrote this message on Thu, Jul 03, 2003 at 04:00 -0700:
> 2. what is the current "best practices" strategy for mounting up a devfs
> in a jail ?
man 8 devfs
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has
On Thu, Jul 03, 2003 at 04:00:46AM -0700 or thereabouts, Josh Brooks wrote:
>
> I have been researching the various of ways people add devfs to a jail to
> give the jail certian /dev devices necessary to function ...
Well, all I did was test your research :-)
>
> One str
I have been researching the various of ways people add devfs to a jail to
give the jail certian /dev devices necessary to function ...
One strategy I saw was:
mount -t devfs devfs /home/jail/dev
( cd /home/jail/dev ; rm $devices_i_dont_want_in_my_jails )
mount -u -o nonewdev /home/jail/dev
On Tue, Nov 06, 2001 at 05:16:31PM +0100, Dag-Erling Smorgrav wrote:
> Kevin D.Wooten <[EMAIL PROTECTED]> writes:
> > Well the linux devfs has a compatibility mode that maintains a /dev
> > that looks exactly like pre-devfs ( the actual list of files is
> > static )
> What's the point with having device nodes for devices you don't have?
A warm fuzzy feeling of having all the device nodes you're used to,
even if the devices don't exist? :-)
Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe f
In message <[EMAIL PROTECTED]> Dag-Erling Smorgrav writes:
: Kevin D.Wooten <[EMAIL PROTECTED]> writes:
: > Well the linux devfs has a compatibility mode that maintains a /dev
: > that looks exactly like pre-devfs ( the actual list of files is
: > static ), and only links u
ce in the same FS, they can share the vnode,
> > otherwise, they cannot.)
>
> This is not how it works. The specfs/devfs will return
> the same vnode.
>
> A "special device" file type in the traditional sense is
> a major/minor/{block|character} tuple.
>
>
nnot.)
This is not how it works. The specfs/devfs will return
the same vnode.
A "special device" file type in the traditional sense is
a major/minor/{block|character} tuple.
The entry in an FS that references this is _not_ where
the vnode comes from, it's a hint to tell the system
s ip. */
ino = ip->i_number;
vgone(*vpp);
error = VFS_VGET(ap->a_dvp->v_mount, ino, vpp);
I wonder with the use of DEVFS, the special device aliases may no longer
exist because they are created by kernel instead of by administrators.
-Zhihui
> The reaso
Zhihui Zhang wrote:
> According to the red daemon book, alias vnodes are used to make cache
> coherent (vp as a key). But getblk() stuff does not seem to check it.
> This makes me feel the code is there for historical reasons.
The "BSD 4.4" book was written about a system without a
unified VM an
ufs_vinit() from ffs_vget() and ufs_vinit() calls addaliasu() to add the
vnode to the alias list. So why reload? The alias vnode is already
handled after it calls ufs_makeinode().
Since DEVFS is in use, will it prevent a user from creating alias names to
the same device? If so, there is no need
In message <[EMAIL PROTECTED]>, Dima Dorfman write
s:
>Brian Somers <[EMAIL PROTECTED]> writes:
>> This looks good. I'd say you should commit the change yourself -
>> feel free to say it's reviewed by me.
>
>I'm not a src/ committer.. :-/
If you have a "reviewed by" an old hand like Brian, then
Brian Somers <[EMAIL PROTECTED]> writes:
> This looks good. I'd say you should commit the change yourself -
> feel free to say it's reviewed by me.
I'm not a src/ committer.. :-/
> As an aside, when I did this to if_tun, I chose to do all the
> destroy_dev()s at module unload time (I guess th
device that wasn't already opened, so the
destroy_dev() looks ok here in practice.
> Brian Somers <[EMAIL PROTECTED]> writes:
> > I haven't actually tested the code, but looking at the patch, I think
> > there's a problem with it...
> >
> > Specificall
Brian Somers <[EMAIL PROTECTED]> writes:
> I haven't actually tested the code, but looking at the patch, I think
> there's a problem with it...
>
> Specifically, on a non-devfs system - where the device nodes are
> created with mknod(1), snp_clone() isn't
I haven't actually tested the code, but looking at the patch, I think
there's a problem with it...
Specifically, on a non-devfs system - where the device nodes are
created with mknod(1), snp_clone() isn't going to be called before
snpopen().
I've (ab)used drv2 as a
Attached is a patch to make the snp(4) driver play ball with DEVFS.
For better or for worse, I used the bpf(4) driver as a guide on how to
do this.
If someone could review this, and, if nothing is wrong with it, commit
it, I'd appreciate it.
Thanks in ad
Greg Lehey wrote:
> On Friday, 2 February 2001 at 20:10:10 -0800, Peter Wemm wrote:
> > Robert Watson wrote:
> >
> >> crw-r--r-- 1 root wheel 78, 0 Dec 31 1969 pci
> >
> > This one may appear harmless, but it is not. It is trivially easy to creat
e
> > an alignment fault (fatal
On Friday, 2 February 2001 at 20:10:10 -0800, Peter Wemm wrote:
> Robert Watson wrote:
>
>> crw-r--r-- 1 root wheel 78, 0 Dec 31 1969 pci
>
> This one may appear harmless, but it is not. It is trivially easy to create
> an alignment fault (fatal on an alpha) with the userland pcicon
Robert Watson wrote:
> crw-r--r-- 1 root wheel 78, 0 Dec 31 1969 pci
This one may appear harmless, but it is not. It is trivially easy to create
an alignment fault (fatal on an alpha) with the userland pciconf tool.
We must not allow this to be used by users until the kernel part i
Driver developers!
As you probably know by now, Poul-Henning has enabled DEVFS in the GENERIC
kernel on FreeBSD 5.0-CURRENT. This is a strong feature and it's great to
see it getting brought back to life. However! Many of consumers of
make_dev() have chosen their default permissions som
I just glanced at it and see no major mistakes.
Sorry I don't have time for a real review.
Poul-Henning
In message <[EMAIL PROTECTED]>, Maksim Yevmenkin
writes:
>--0-783368690-973704660=:11219
>Content-Type: text/plain; charset=us-ascii
>Content-Disposition: inline
>
>Hello All,
>
>anyone wan
Hello All,
anyone wants to review and commit the following patch.
thanks,
emax
__
Do You Yahoo!?
Thousands of Stores. Millions of Products. All in one Place.
http://shopping.yahoo.com/
if_tap.c.diff
Hello Harti,
> > > is there somebody working to make if_tap devfs-ready? Or I'm doing
> > > something wrong?
> >
> > [SNIP]
> > it seems to me that it did not get commited. i will look into it again
> > today and re-send patch to the list.
>
On Mon, 6 Nov 2000, Maksim Yevmenkin wrote:
Hi Maksim,
> > is there somebody working to make if_tap devfs-ready? Or I'm doing
> > something wrong?
>
> [SNIP]
> it seems to me that it did not get commited. i will look into it again
> today and re-send patch to the li
Hello,
> I recently moved to using devfs and now if_tap seems unusable. Although
> the module is loaded, it doesn't show up in /dev or as an interface.
> >From a quick comparison with if_tun it seems that this is 'expected'
> behaviour although I'm not a specia
Hello,
I recently moved to using devfs and now if_tap seems unusable. Although
the module is loaded, it doesn't show up in /dev or as an interface.
>From a quick comparison with if_tun it seems that this is 'expected'
behaviour although I'm not a specialist with devfs.
On Tue, 19 Sep 2000, Bruce Evans wrote:
> On Sun, 17 Sep 2000, Adrian Filipi-Martin wrote:
>
> > I recently ran into revelant problem with /dev/stdout, while
> > working on some software under linux that expected /dev/stdout as an
> > argument instead of using stdout.
> >
> > Using the
On Sun, 17 Sep 2000, Adrian Filipi-Martin wrote:
> I recently ran into revelant problem with /dev/stdout, while
> working on some software under linux that expected /dev/stdout as an
> argument instead of using stdout.
>
> Using the device file breaks, if the process is suid to a non
On Thu, 14 Sep 2000, Ben Smithurst wrote:
> Poul-Henning Kamp wrote:
>
> > I must admit that I think in general that /dev/std{in,out,err} and /dev/fd
> > is bogus. It looks like something which happened "because we can" more
> > than something which has a legitimate need.
>
> You think adding
using Brian's post since I don't have the original around ...
On Sat, Sep 16, 2000 at 03:49 +0100, Brian Somers wrote:
>
> [ attribution missing, is it Poul-Henning Kamp's text? ]
>
> > The majority of these programs could be handled by adding
> > knowledge of "-" as a magic filename to fopen(3
> The majority of these programs could be handled by adding knowledge
> of "-" as a magic filename to fopen(3).
[.]
> I would argue that the programs and the scripts that call them are
> already broken, but hey...
So (just to add fuel to the mass opposition), do this without
temporary files:
On Thu, 14 Sep 2000, Julian Elischer wrote:
> I've never thought of a use for fdescfs...
I used /dev/fd/1 just yesterday for a third-party precompiled binary
that insists on outputting to a file specified on the command line.
Slapping in /dev/fd/1 lets me stuff the command in a pipe chain. Same
On Thu, Sep 14, 2000 at 02:37:06PM +0200, Poul-Henning Kamp wrote:
[...]
> The majority of these programs could be handled by adding knowledge
> of "-" as a magic filename to fopen(3).
>
> At the same time I would really love if we implemented "|.*" to mean
> "do an popen(3)" instead.
This would
On 14-Sep-00 at 05:37, Poul-Henning Kamp ([EMAIL PROTECTED]) wrote:
> >You think adding a hack to every program to support "-" to mean
> >stdout/stdin is better?
>
> The majority of these programs could be handled by adding knowledge
> of "-" as a magic filename to fopen(3).
>
> At the same time
1 - 100 of 193 matches
Mail list logo
