Re: [Cooker] Re: Problems in drakxtools regarding ltmodem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Luca Berra wrote: > On Mon, Aug 25, 2003 at 08:54:48PM +0200, Buchan Milne wrote: > >> It seems to work correctly now (if no /dev/modem link is made), but I >> think I will have to remove the packages (or do a clean install) and >> test again to be sure. I will try again on current cooker. > > /dev/modem is evil and should not exist. > unluckily serial port locking works using a file in /var/lock named > after the device node. > If you have /dev/modem linked to /dev/ttyS2 you could open the same > device under two different names from two different apps and this could > produce nightmares and other nuisances. Well, I am not debating whether /dev/modem is a good idea or not, but it would be much more work to support anything but /dev/modem (which drakconnect sets kppp up for etc etc). But if /dev/modem is going to be used for ltmodem, at least it should work. Of course, having drakconnect use /dev/tts/LT0 would be better, but that's not for this Mandrake release I think (too late). ltmodem's are most popular on laptops, so in most cases I think it's not an issue that it can be locked, since it's not likely (or the user is clueless). Regards, Buchan - -- |--Another happy Mandrake Club member--| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x202 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/SonkrJK6UGDSBKcRAnepAJ97s3PpgC8/cFh/ndaN2MrlF3nbMACgllvj r/qnp6V1Y8tjgO7FUS8Ocv4= =LUhF -END PGP SIGNATURE- * Please click on http://www.cae.co.za/disclaimer.htm to read our e-mail disclaimer or send an e-mail to [EMAIL PROTECTED] for a copy. *
Re: [Cooker] Re: Problems in drakxtools regarding ltmodem
On Mon, Aug 25, 2003 at 08:54:48PM +0200, Buchan Milne wrote: It seems to work correctly now (if no /dev/modem link is made), but I think I will have to remove the packages (or do a clean install) and test again to be sure. I will try again on current cooker. /dev/modem is evil and should not exist. unluckily serial port locking works using a file in /var/lock named after the device node. If you have /dev/modem linked to /dev/ttyS2 you could open the same device under two different names from two different apps and this could produce nightmares and other nuisances. regards, L. -- Luca Berra -- [EMAIL PROTECTED] Communication Media & Services S.r.l. /"\ \ / ASCII RIBBON CAMPAIGN XAGAINST HTML MAIL / \
[Cooker] Re: Problems in drakxtools regarding ltmodem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 François Pons wrote: > Buchan Milne <[EMAIL PROTECTED]> writes: > > >>I would like to see ltmodem support out-the-box for boxed sets, and have >>working packages, that with drakconnect (on beta2) do most things right >>(drakconnect will install them when a ltmodem is found if they are >>accessible by urpmi). >> >>The problem is still that drakconnect for some reason insists on making a >>link for /dev/modem (at present it asks you which of 8 serial ports to >>use, or if /usr/lib/libDrakx/network/modem.pm is patched, whatever device >>is listed there for ltmodem, in 9.1 this was ttyS14), and this breaks >>auto-loading of the lt_serial module (which works via 'alias /dev/modem >>lt_serial' in modules.conf, and registering the symlink via devfs). > > > At the epoch it has been made necessary to do that else it will not work. > > But now, if it works out of the box correctly (it could be nice if it works even > if devfs is not used too) we can remove this. It seems to work correctly now (if no /dev/modem link is made), but I think I will have to remove the packages (or do a clean install) and test again to be sure. I will try again on current cooker. I can't see an easy way to get it working without devfs without breaking with devfs. We could always leave the link /dev/modem->/dev/tts/0, and put lt_serial in /etc/modules, but it's messier, and not necessary IMHO to load a non-GPL driver for a device that may not always be used. I don't mind which way to go, but I would like to see this work out-the-box, and can test it a few times. Of course, the other thing would be to get the package on the commercial packs .. hope someone can organise this ... Regards, Buchan - -- |--Another happy Mandrake Club member--| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x202 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/Slt3rJK6UGDSBKcRAg5rAJ9UNQmJPZBEnn5hdkRBAFvERzNZPwCfYNpl ktxEvgbzAdqjA57TQMUJ+JE= =KIEG -END PGP SIGNATURE- * Please click on http://www.cae.co.za/disclaimer.htm to read our e-mail disclaimer or send an e-mail to [EMAIL PROTECTED] for a copy. *
[Cooker] Re: Problems in drakxtools regarding ltmodem
Buchan Milne <[EMAIL PROTECTED]> writes: > I would like to see ltmodem support out-the-box for boxed sets, and have > working packages, that with drakconnect (on beta2) do most things right > (drakconnect will install them when a ltmodem is found if they are > accessible by urpmi). > > The problem is still that drakconnect for some reason insists on making a > link for /dev/modem (at present it asks you which of 8 serial ports to > use, or if /usr/lib/libDrakx/network/modem.pm is patched, whatever device > is listed there for ltmodem, in 9.1 this was ttyS14), and this breaks > auto-loading of the lt_serial module (which works via 'alias /dev/modem > lt_serial' in modules.conf, and registering the symlink via devfs). At the epoch it has been made necessary to do that else it will not work. But now, if it works out of the box correctly (it could be nice if it works even if devfs is not used too) we can remove this. Best Regards, François.
