:To sum it up, prepending "serno/" to your call to getsynthvnode, if
:you look for a serial number, should do the job.
:
:Cheers,
:
:Alex Hornung
Ah, ok. Well, then theoretically a vinum root is possible. I haven't
tried it though.
-M
.
To sum it up, prepending "serno/" to your call to getsynthvnode, if
you look for a serial number, should do the job.
Cheers,
Alex Hornung
2009/8/15 Matthew Dillon :
> The vinum softraid driver should now be operational with devfs
> in the master repo. vinum should no
The vinum softraid driver should now be operational with devfs
in the master repo. vinum should now be able to handle full 64 bit
geometries (multi-terrabyte disk subsystems).
In addition, vinum configurations may reference devices by serial
number or devtab label. for
DEVFS has gone through a bunch of debug and fix passes since the
initial integration and is now ready for even wider testing on master.
* Now works properly with X.
* Now works properly with mono and other applications.
* Now probes disklabels in GPT slices, and properly
ved.
Also note that vinum is not operational in master at the moment.
--
DEVTAB - Add mountroot & fstab support for serial numbers, and devtab.
* The vfs.root.mountfrom /boot/loader.conf variable may now specify
devfs aliases, allowing it to specify root mount
:>> - TAPDEV_MAJOR(st.st_rdev) == TAP_CDEV_MAJOR) {
:>> - *tap_unit = TAPDEV_MINOR(st.st_rdev);
:>> -
:>> + sscanf(tap_dev, "/dev/tap%d", tap_unit) == 1) {
:>> /*
:...
:
:Oh, I won't call that patch a `fix', it was just a bandaid for me.
:However, just opening /de
On Mon, Aug 03, 2009 at 10:16:25PM -0700, Matthew Dillon wrote:
> * If you run a new kernel with an old world (without devfs) you will
> not be able to login as root, but you will still be able to login
> as a user and su, and you should still be able to boot si
On Wed, Aug 05, 2009 at 12:44:01PM +0200, Simon 'corecode' Schubert wrote:
> YONETANI Tomokazu wrote:
>> diff --git a/sys/platform/vkernel/platform/init.c
>> b/sys/platform/vkernel/platform/init.c
>> index 2d3fd72..7caaf5b 100644
>> --- a/sys/platform/vkernel/platform/init.c
>> +++ b/sys/platform/
Alex wrote:
Short update:
It turns out that ls is doing something ugly: it is retrieving the
major and minor from the udev, which isn't constructed anymore from
major and minor. What I will be doing is change ls to work properly
and commit it later this afternoon together with another bunch of
c
Short update:
It turns out that ls is doing something ugly: it is retrieving the
major and minor from the udev, which isn't constructed anymore from
major and minor. What I will be doing is change ls to work properly
and commit it later this afternoon together with another bunch of
changes/fixes.
Hi,
about if_tap, it should in theory autoclone on opening /dev/tap and
using fdevname or fdevname_r to retrieve the name from the open
descriptor. It is untested, but the code is present and should work at
least as far as creating the clone device.
As for major/minor goes, major is set to 0 alwa
YONETANI Tomokazu wrote:
diff --git a/sys/platform/vkernel/platform/init.c
b/sys/platform/vkernel/platform/init.c
index 2d3fd72..7caaf5b 100644
--- a/sys/platform/vkernel/platform/init.c
+++ b/sys/platform/vkernel/platform/init.c
@@ -955,9 +955,7 @@ netif_open_tap(const char *netif, int *tap_uni
Hi.
Is there any policy on how device major/minor numbers are determined?
I haven't gone through the devfs change, but `ls -l /dev' looks
a bit weird :), in that most of device nodes have either 0 or 2 as
their major number, and the minor number are rather high.
I noticed that while I
Initial serial number support is now on master. Serial numbers show
up in the /dev/serno directory. All CAM and NATA drives which attach
with serial numbers will show up. Note that many USB drives do not
report serial numbers and may not show up in any meaningful way.
The or
Alex's GSOC project, DEVFS is now on master and active. Some care must
be taken when upgrading.
* A full buildworld, buildkernel, installkernel, installworld sequence
is needed. No changes to fstab are needed, /dev will be mounted
from devfs automatically by the k
Alex's DEVFS SOC work will be integrated into the git master this
weekend. The development system may be unstable for a week or so after
the integration. Anyone upgrading after the work is committed must
take care to upgrade both their kernel and the world.
We are al
I've got about another week to go on the AHCI driver and then I'll
really start playing with DEVFS and AMD64 in earnest.
-Matt
Matthew Dillon
Alex Hornung schrieb:
- The promised devfs userland daemon is still non-existant
Don't we have devd(8) for that already?
Sascha
--
http://yoyodyne.ath.cx
Hi,
I just wanted to give a short (PS: or actually not-so-short) status
update in case anyone is interested on how devfs is going.
If you decide for whatever (insane) reason to try the code (which is in
my repository, branch devfs, and will be broken more often than working)
please do so in a
My current code is at:
> http://gitweb.dragonflybsd.org/~alexh/dragonfly.git/tree/aae02cbf0350ca50b64b381042f7eea01a44c1bc:/sys/vfs/devfs
>
>
> About devfs status:
> While I'm still dealing with the above panic and the code isn't cleaned
> up and there might still be some locking issues, devfs al
7;d appreciate it.
My current code is at:
http://gitweb.dragonflybsd.org/~alexh/dragonfly.git/tree/aae02cbf0350ca50b64b381042f7eea01a44c1bc:/sys/vfs/devfs
About devfs status:
While I'm still dealing with the above panic and the code isn't cleaned
up and there might still be some locki
Alex Hornung wrote:
> There will also be a userland daemon which will receive notifications
> of new devices; this daemon will basically be used to keep a
> configuration file for devfs including permissions and hence telling
> the devfs in the kernel which permissions to use to creat
:...
:I intend to keep a page on http://leaf.dragonflybsd.org/~alexh/ about
:the progress on DevFS. It currently is a bit outdated as there is still
:the original idea about a proposal for DevFS. Also, if you happen to
:look around, both the LLVM/clang and I/O Scheduler pages need a major
Hi all,
as you know I'll be working on DevFS for Google Summer of Code 2009.
Some of you may know me already either from IRC, from random rant at the
bug tracker or from my clang related mails to this list. For those who
don't, a brief introduction:
I'm an Electronic Engineering
Hi all:
I'm a newbie and trying to make a userland devfs for DFly and the
design is much more
like devctl.
The logic is kernel provide a device named udev, in d_open the
device copyout list of devices.
I inject the make_dev in kern_conf.c with udev_attach().
The userland daemon udevd ope
Dmitry Komissaroff wrote:
Simon 'corecode' Schubert пишет:
Dmitry Komissaroff wrote:
I think anyone agree with benefits of devfs. Limited number of dev
files really existed hardware in /dev is one of them.
And then question: is someone plan to port devfs?
No, nobody does. Also,
Simon 'corecode' Schubert пишет:
Dmitry Komissaroff wrote:
I think anyone agree with benefits of devfs. Limited number of dev
files really existed hardware in /dev is one of them.
And then question: is someone plan to port devfs?
No, nobody does. Also, it is not clear whether a
Simon 'corecode' Schubert wrote:
> What I'd like to see is a twofold scheme: A virtual devfs, plus
> udev-alike functionality:
>
> - The devfs will show all existing devices with their standard names, and
> only those.
> - have userland set permissions
r a Linux udev
like scheme (Events generated by kernel & /dev housekeeping via a
userland daemon).
Yah, that might but not current anymore :)
What I'd like to see is a twofold scheme: A virtual devfs, plus
udev-alike functionality:
- The devfs will show all existing devices with th
"Simon 'corecode' Schubert" <[EMAIL PROTECTED]> writes:
Hello,
> No, nobody does. Also, it is not clear whether a port would be good or
> whether rewriting it from scratch would be better.
Iirc, Matt eplained a long time ago that he would prefer a Linux udev
like scheme (Events generated by ker
Dmitry Komissaroff wrote:
I think anyone agree with benefits of devfs. Limited number of dev files
really existed hardware in /dev is one of them.
And then question: is someone plan to port devfs?
No, nobody does. Also, it is not clear whether a port would be good or
whether rewriting it
Hi All.
I think anyone agree with benefits of devfs. Limited number of dev files
really existed hardware in /dev is one of them.
And then question: is someone plan to port devfs?
On 2006-01-21, Matthew Dillon <[EMAIL PROTECTED]> wrote:
> A devfs is not going to impact performance. That isn't the problem
> with it. There are three problems with it.
Maybe I missed something, but as I see this thread mentioned performance
only in connection wit
33 matches
Mail list logo
